Messages in this thread | | | Date | Mon, 3 May 2010 16:11:10 -0400 (EDT) | From | Alan Stern <> | Subject | Re: s2ram slow (radeon) / failing (usb) |
| |
On Mon, 3 May 2010, Bruno [UTF-8] Prémont wrote:
> On Mon, 03 May 2010 Alan Stern <stern@rowland.harvard.edu> wrote: > > You might also want to #define VERBOSE_DEBUG at the start of > > drivers/usb/core/driver.c, before the first #include. > > Still no difference... (will retry with own printk's in ohci's suspend > code as suggested in other mail)
First of all, have you tried disabling async suspend? Look at /sys/power/pm_async.
> Suspend output as it goes:
Let's just look at the USB entries:
> [ 241.358651] usb usb1: preparing type suspend, may wakeup > [ 241.364247] usb usb2: preparing type suspend, may wakeup > [ 241.369847] usb usb3: preparing type suspend, may wakeup > [ 241.375443] usb usb4: preparing type suspend, may wakeup > [ 241.381044] usb usb5: preparing type suspend, may wakeup > [ 241.386643] usb usb6: preparing type suspend, may wakeup > [ 241.392244] usb 1-2: preparing type suspend, may wakeup > [ 241.397762] usb 1-2.1: preparing type suspend, may wakeup
Those are normal.
> [ 241.407504] usbhid 1-2.1:1.1: suspend > [ 241.407511] usbhid 1-2.1:1.0: suspend
These are HID suspends for the keyboard and mouse interfaces.
> [ 241.407516] usb 1-2.1: type suspend, may wakeup
This is a USB suspend for the KB/mouse device.
> [ 241.443340] hub 1-2:1.0: suspend
Suspend for the embedded hub interface. Next we should see
[....] usb 1-2: type suspend, may wakeup
for the embedded hub device, but we don't. That's the problem. It must be waiting for something -- goodness knows what.
> [ 241.911502] hub 6-0:1.0: suspend > [ 241.914928] usb usb6: type suspend, may wakeup > [ 241.919583] usb usb6: usb_suspend_both: status 0 > [ 241.924448] usb usb6: suspend, may wakeup > [ 241.928663] hub 5-0:1.0: suspend > [ 241.932082] usb usb5: type suspend, may wakeup > [ 241.936794] usb usb5: usb_suspend_both: status 0 > [ 241.941669] usb usb5: suspend, may wakeup > [ 241.945888] hub 4-0:1.0: suspend > [ 241.949294] usb usb4: type suspend, may wakeup > [ 241.953966] usb usb4: usb_suspend_both: status 0 > [ 241.958814] usb usb4: suspend, may wakeup > [ 241.963069] hub 3-0:1.0: suspend > [ 241.966452] usb usb3: type suspend, may wakeup > [ 241.971126] usb usb3: usb_suspend_both: status 0 > [ 241.976015] usb usb3: suspend, may wakeup > [ 241.980232] hub 2-0:1.0: suspend > [ 241.983662] usb usb2: type suspend, may wakeup > [ 241.988316] usb usb2: usb_suspend_both: status 0 > [ 241.993192] usb usb2: suspend, may wakeup > [ 241.997418] hub 1-0:1.0: suspend
And here we should see
[....] usb usb1: type suspend, may wakeup etc.
but we don't, because it's waiting for the 1-2 device.
> [ 242.125768] ehci_hcd 0000:00:13.5: suspend > [ 242.130076] ehci_hcd 0000:00:13.5: PCI INT D disabled > [ 242.135410] ohci_hcd 0000:00:13.4: suspend > [ 242.139696] ohci_hcd 0000:00:13.4: PCI INT C disabled > [ 242.145035] ohci_hcd 0000:00:13.3: suspend > [ 242.149348] ohci_hcd 0000:00:13.3: PCI INT B disabled > [ 242.154705] ohci_hcd 0000:00:13.2: suspend > [ 242.159012] ohci_hcd 0000:00:13.2: PCI INT C disabled > [ 242.164342] ohci_hcd 0000:00:13.1: suspend > [ 242.168676] ohci_hcd 0000:00:13.1: PCI INT B disabled
> I guess here PM is waiting for ohci_hcd 0000:00:13.0 to suspend > and disable its interrupt. > (and that last ohci device would match the usbhid_resume thread that's > frozen...)
The 0000:00:13.0 device can't suspend until usb1 does, and usb1 can't suspend until 1-2 does.
Can you boot the dmesg log for bootup and device detection? It may indicate what we're missing. Also include the contents of /sys/kernel/debug/usb/devices.
Alan Stern
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |