Most recent kernel where this bug did *NOT* occur: 18.104.22.168
Hardware Environment: x86_64
Suspends to disk fine, but when resuming it breaks due to USB. I have confirmed
by suspending to disk and resuming without USB compiled in. I don't have time to
do a bisect tonight, but will try to track this down within the next 48 hours if
my dmesg doesn't give enough hints within that time. Anything I can do please
let me know.
Steps to reproduce:
Created attachment 11533 [details]
This is the bad dmesg, contains the BUG and more
Created attachment 11534 [details]
The config used to get this dmesg
Bisect this patch is the guilty party.
6b157c9bf3bace6eeb4a973da63923ef24995cce is first bad commit
Author: Alan Stern <email@example.com>
Date: Tue Mar 13 16:37:30 2007 -0400
USB: separate autosuspend from external suspend
This patch (as866) adds new entry points for external USB device
suspend and resume requests, as opposed to internally-generated
autosuspend or autoresume. It also changes the existing
remote-wakeup code paths to use the new routines, since remote
is not the same as autoresume.
As part of the change, it turns out to be necessary to do remote
wakeup of root hubs from a workqueue. We had been using khubd, but
does autoresume rather than an external resume. Using the
ksuspend_usb_wq workqueue for this purpose seemed a logical choice.
Signed-off-by: Alan Stern <firstname.lastname@example.org>
Signed-off-by: Greg Kroah-Hartman <email@example.com>
(You can probably work around this by unloading usb before suspend).
Please try applying this patch:
If it doesn't help, then build a kernel with CONFIG_USB_DEBUG turned on (and
that patch applied) and attach the dmesg log showing the problem.
Aah, That works, thanks for the fix!
Is this in the queue for -rc3?
The patch is in Greg KH's queue. I don't know when he is planning on sending it
to Linus, but if we inform him that it solves your suspend problem then he will
probably expedite matters. I'll let him know.
shipped in Linux-2.6.22-rc3