This is a discussion on WARNING: at kernel/power/main.c:176 suspend_test_finish+0x70/0x80() - Kernel ; 2.6.27 seems to be taking long time to resume, it hits this WARN_ON in
kernel/power/main.c:176 suspend_test_finish -
Never seen earlier.
[ 295.600086] PM: resume devices took 10.180 seconds
[ 295.600091] ------------[ cut here ]------------
[ 295.600092] WARNING: at kernel/power/main.c:176
suspend_test_finish+0x70/0x80()
...

On Fri, 10 Oct 2008, Rafael J. Wysocki wrote:
> On Friday, 10 of October 2008, Parag Warudkar wrote:
> > 2.6.27 seems to be taking long time to resume, it hits this WARN_ON in
> > kernel/power/main.c:176 suspend_test_finish -
> > Never seen earlier.
>
> Resuming devices takes too much time (more than 5 sec. actually)
> and the stack trace indicates USB.
>
> Can you test with the USB modules unloaded?

There's a bug that affects USB power management: commmit
f9dd45ce10a014bdfd5432828c44630ea7fefedd needs to be reverted. Greg KH
has been asked to do this a few times but he hasn't gotten around to it
yet.

On Fri, Oct 10, 2008 at 10:31 AM, Alan Stern wrote:
> There's a bug that affects USB power management: commmit
> f9dd45ce10a014bdfd5432828c44630ea7fefedd needs to be reverted. Greg KH
> has been asked to do this a few times but he hasn't gotten around to it
> yet.

Hi Alan,

Thanks for the info.

I can't seem to find that commit in mainline. If you have pointer to
the patch I will submit a revert.

On Fri, 10 Oct 2008, Parag Warudkar wrote:
> On Fri, Oct 10, 2008 at 10:31 AM, Alan Stern wrote:
>
> > There's a bug that affects USB power management: commmit
> > f9dd45ce10a014bdfd5432828c44630ea7fefedd needs to be reverted. Greg KH
> > has been asked to do this a few times but he hasn't gotten around to it
> > yet.
>
> Hi Alan,
>
> Thanks for the info.
>
> I can't seem to find that commit in mainline. If you have pointer to
> the patch I will submit a revert.

It isn't in mainline; it's in linux-next. Sorry, I wasn't sure which
kernel you were using.

On Friday, 10 of October 2008, Alan Stern wrote:
> On Fri, 10 Oct 2008, Parag Warudkar wrote:
>
> > On Fri, Oct 10, 2008 at 10:31 AM, Alan Stern wrote:
> >
> > > There's a bug that affects USB power management: commmit
> > > f9dd45ce10a014bdfd5432828c44630ea7fefedd needs to be reverted. Greg KH
> > > has been asked to do this a few times but he hasn't gotten around to it
> > > yet.
> >
> > Hi Alan,
> >
> > Thanks for the info.
> >
> > I can't seem to find that commit in mainline. If you have pointer to
> > the patch I will submit a revert.
>
> It isn't in mainline; it's in linux-next. Sorry, I wasn't sure which
> kernel you were using.

I understood it was the mainline from the report.

Parag, could you please try to suspend without the USB drivers and see if the
delay is still there?

On Fri, 10 Oct 2008, Rafael J. Wysocki wrote:
> I understood it was the mainline from the report.
>
> Parag, could you please try to suspend without the USB drivers and see if the
> delay is still there?

Or even better, suspend with the USB drivers present, and with
CONFIG_USB_DEBUG, CONFIG_PM_SLEEP, and CONFIG_PRINTK_TIME all enabled.
The resulting detailed timing information should pinpoint the problem.

On Fri, Oct 10, 2008 at 3:34 PM, Rafael J. Wysocki wrote:
>> It isn't in mainline; it's in linux-next. Sorry, I wasn't sure which
>> kernel you were using.
>
> I understood it was the mainline from the report.
>
> Parag, could you please try to suspend without the USB drivers and see if the
> delay is still there?
>
Hi Rafael,

On Fri, Oct 10, 2008 at 3:44 PM, Alan Stern wrote:
> Or even better, suspend with the USB drivers present, and with
> CONFIG_USB_DEBUG, CONFIG_PM_SLEEP, and CONFIG_PRINTK_TIME all enabled.
> The resulting detailed timing information should pinpoint the problem.

As of now it is reproducible without USB modules loaded. But any way
will try this over weekend.