Bug 8498 - BUG: 2.6.22-rc1+ resume after suspend-to-disk broken when USB compiled in.
Summary: BUG: 2.6.22-rc1+ resume after suspend-to-disk broken when USB compiled in.
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Alan Stern
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2007-05-17 21:53 UTC by Avuton Olrich
Modified: 2007-07-25 22:55 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.22-rc1-d3a36fb82a0864a85e238ac946817030a18c5f9a
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg (28.73 KB, text/plain)
2007-05-17 21:56 UTC, Avuton Olrich
Details
The config used to get this dmesg (36.19 KB, text/plain)
2007-05-17 21:58 UTC, Avuton Olrich
Details

Description Avuton Olrich 2007-05-17 21:53:08 UTC
Most recent kernel where this bug did *NOT* occur: 2.6.21.1
Distribution: Gentoo
Hardware Environment: x86_64
Software Environment:
Problem Description:

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:
Comment 1 Avuton Olrich 2007-05-17 21:56:16 UTC
Created attachment 11533 [details]
dmesg

This is the bad dmesg, contains the BUG and more
Comment 2 Avuton Olrich 2007-05-17 21:58:18 UTC
Created attachment 11534 [details]
The config used to get this dmesg
Comment 3 Avuton Olrich 2007-05-18 05:27:55 UTC
Bisect this patch is the guilty party.

6b157c9bf3bace6eeb4a973da63923ef24995cce is first bad commit
commit 6b157c9bf3bace6eeb4a973da63923ef24995cce
Author: Alan Stern <stern@rowland.harvard.edu>
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
wakeup
    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
it
    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 <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Comment 4 Pavel Machek 2007-05-18 06:09:52 UTC
(You can probably work around this by unloading usb before suspend).
Comment 5 Alan Stern 2007-05-18 07:39:53 UTC
Please try applying this patch:

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb/usb-make-the-autosuspend-workqueue-thread-freezable.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.
Comment 6 Avuton Olrich 2007-05-18 15:04:14 UTC
Aah, That works, thanks for the fix!
Comment 7 Avuton Olrich 2007-05-19 06:00:40 UTC
Is this in the queue for -rc3?
Comment 8 Alan Stern 2007-05-19 08:08:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.