Suspend/Resume breaks onboard USB in Feisty

[Brett Clippingdale]

Onboard USB ports fail after resume on IBM Thinkpad T30. Unplugging/replugging devices does not help. USB ports on PCMCIA work fine.

dmesg includes:
Apr 8 12:22:05 boca kernel: [55241.392000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Apr 8 12:22:05 boca kernel: [55241.392000] usb usb1: root hub lost power or was reset

Similar messages are generated for 3 usb ports (the T30 actually has 2, but anyway ...)

I am running Feisty Beta, fully up-to-date, and this has been a problem for all kernels tried so far: from 2.6.20-12 through 2.6.20-15:
brett@boca:~$ uname -a
Linux boca 2.6.20-15-generic #2 SMP Fri Apr 13 16:33:26 UTC 2007 i686 GNU/Linux

Please see below for info from lspci and dmesg.

FWIW, this did not happen on Fedora Core 6.

[Brett Clippingdale (brett-clippingdale)]

lspci -vv

[Brett Clippingdale (brett-clippingdale)]

lspci -vvn

Note that both onboard and PCMCIA USB ports/hubs are listed here.

[Brett Clippingdale (brett-clippingdale)]

Note that USB kernel modules appear to be fine:

**************************************
Before suspend:

brett@boca:~$ lsmod | grep hci
uhci_hcd 25360 0
usbcore 134280 4 xpad,usbhid,uhci_hcd
brett@boca:~$ lsmod | grep usb
usbhid 26592 0
hid 27392 1 usbhid
usbcore 134280 4 xpad,usbhid,uhci_hcd
brett@boca:~$

**********************************
After suspend: (no change here)

brett@boca:~$ lsmod | grep usb
usbhid 26592 0
hid 27392 1 usbhid
usbcore 134280 4 xpad,usbhid,uhci_hcd
brett@boca:~$ lsmod | grep hci
uhci_hcd 25360 0
usbcore 134280 4 xpad,usbhid,uhci_hcd
brett@boca:~$

(not sure why xpad is loading. I have a MS mouse and MS keyboard, but no XBox!)

[Brett Clippingdale (brett-clippingdale)]

This may be related:

http://<email address hidden>/msg06153.html

[Brett Clippingdale (brett-clippingdale)]

From the dmesg posted above, these lines are most intriguing:

[11582.604000] usb usb1: root hub lost power or was reset
[11582.604000] uhci_hcd 0000:00:1d.1: resuming
[11582.604000] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
[11582.604000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[11582.604000] PCI: Setting latency timer of device 0000:00:1d.1 to 64
[11582.604000] PM: Writing back config space on device 0000:00:1d.1 at offset f (was 200, writing 20b)
[11582.604000] PM: Writing back config space on device 0000:00:1d.1 at offset 8 (was 1, writing 1821)
[11582.604000] usb usb2: root hub lost power or was reset
[11582.604000] uhci_hcd 0000:00:1d.2: resuming
[11582.604000] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
[11582.604000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[11582.604000] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[11582.604000] PM: Writing back config space on device 0000:00:1d.2 at offset f (was 300, writing 30b)
[11582.604000] PM: Writing back config space on device 0000:00:1d.2 at offset 8 (was 1, writing 1841)
[11582.604000] usb usb3: root hub lost power or was reset

[Brett Clippingdale (brett-clippingdale)]

Some progress, but no solution yet.

I tried to make a workaround by manually adjusting /etc/default/acpi-support. I have managed to get rid of the "root hub lost power or was reset" error messages in dmesg, but so far the devices themselves don't work as the USB hubs themselves still seem to be dead.

I think this is the most likely way to fix this problem, unless some ubuntu dev takes a look at this. It really should just work -- It's not a problem in Fedora, for example. The changes I've tried so far:

# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES="em8300 yenta_socket"
#
# Note that network cards and USB controllers will automatically be unloaded
# unless they're listed in MODULES_WHITELIST
#MODULES=""
#MODULES="usbhid hid usblp ehci_hcd ohci_hcd uhci_hcd usbcore"
MODULES="uhci_hcd ehci_hcd ohci_hcd"

I'm hoping that finding the correct combination of modules/combination/(order?) will make this work. I'm also attaching my latest dmesg output. Maybe someone else will find the correct setting.

[Brett Clippingdale (brett-clippingdale)]

Tried experimenting with adding "hid" to MODULES in /etc/default/acpi-support. No luck with that either. However, I did notice the following changes in output of lsusb in before/after suspend/resume:

(BEFORE SUSPEND)
brett@boca:~$ lsusb
Bus 005 Device 002: ID 045e:00dd Microsoft Corp.
Bus 005 Device 001: ID 0000:0000
Bus 006 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 045e:008c Microsoft Corp. Wireless Intellimouse Explorer 2.0
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
brett@boca:~$ lsmod | grep usb
usbhid 26592 0
hid 27392 1 usbhid
usbcore 134280 6 xpad,ehci_hcd,ohci_hcd,usbhid,uhci_hcd
brett@boca:~$ lsmod | grep hci
ehci_hcd 34188 0
ohci_hcd 22532 0
uhci_hcd 25360 0
usbcore 134280 6 xpad,ehci_hcd,ohci_hcd,usbhid,uhci_hcd

(AFTER RESUME)
brett@boca:~$ lsusb
Bus 006 Device 001: ID 0000:0000
Bus 005 Device 002: ID 045e:00dd Microsoft Corp.
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
brett@boca:~$ lsmod | grep hci
ohci_hcd 22532 0
ehci_hcd 34188 0
uhci_hcd 25360 0
usbcore 134280 6 ohci_hcd,ehci_hcd,uhci_hcd,xpad,usbhid
brett@boca:~$ lsmod | grep usb
usbhid 26592 0
hid 27392 1 usbhid
usbcore 134280 6 ohci_hcd,ehci_hcd,uhci_hcd,xpad,usbhid

[Brett Clippingdale (brett-clippingdale)]

Oh, the point of the above lsusb info is that the hub itself doesn't seem to be dead, just that the device that is plugged into it (the MS Intellimouse) doesn't get re-registered (btw, the device plugged into USB hub "005" is an MS keyboard).

Unplugging/replugging does nothing to change this.

[Brett Clippingdale (brett-clippingdale)]

This is a duplicate of bug# 99267:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/99267

[Brett Clippingdale (brett-clippingdale)]

This is also instructive:

http://ubuntuforums.org/showthread.php?p=2579166

[run4flat (linux-davidandkatherine)]

See also bug #103674:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/103674

[Nick (morrownr)]

Confirmed on my T23 running up to date Fiesty. Very annoying.

[hendrixski (hendrixski)]

There seem to be quite a few bugs filed with similar problems
Bug 99267
Bug 105563
Bug 99267
and more

This bug is a show-stopper for anyone with a laptop. I'm on a Toshiba Portégé running feisty with
$ uname -a
*** *** 2.6.20-16-lowlatency #2 SMP PREEMPT Thu Jun 7 20:23:03 UTC 2007 i686 GNU/Linux

I'm attaching my lspci -vvnn information on this post... and since I can only upload one log per post I'll upload dmesg logs next.

[hendrixski (hendrixski)]

I ran dmesg -c after rebooting then inserted a USB, copied some files onto it, then safely removed it. Then I hibernated, then I resumed and re-inserted the USB... nothing happened, then I removed it and the dmesg > dmesg.log output is attached. my lspci and uname -a information is in the post above

Please get this taken care of. thank you.

[Launchpad Janitor (janitor)]

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!