No usb on resume from suspend

[Steve Magoun]

My XPS13 running 14.04 sometimes loses its USB ports after resume from suspend. When this happens the entire bus seems dead - both external ports do not work, and internal USB devices (webcam, touchscreen) are also non-functional. Furthermore lsusb shows no devices attached. Rebooting or performing another suspend/resume cycle will clear the problem.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-17-generic 3.13.0-17.37
ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6
Uname: Linux 3.13.0-17-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: steve 2868 F.... pulseaudio
 /dev/snd/controlC0: steve 2868 F.... pulseaudio
CurrentDesktop: Unity
Date: Thu Mar 13 08:36:46 2014
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-precise-amd64-20130203-1
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=79084358-087f-4cee-a0be-e2f78361873f
InstallationDate: Installed on 2013-12-02 (100 days ago)
InstallationMedia: Ubuntu 12.04 "Precise" - Build amd64 LIVE Binary 20130203-13:50
Lsusb:
 Bus 001 Device 002: ID 8087:8000 Intel Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. XPS13 9333
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-17-generic root=UUID=0b9db31c-747b-40ad-bbbd-13a9a29caece ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-17-generic N/A
 linux-backports-modules-3.13.0-17-generic N/A
 linux-firmware 1.126
RfKill:
 1: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: Upgraded to trusty on 2014-02-12 (28 days ago)
dmi.bios.date: 11/11/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A01
dmi.board.name: 0GFTRT
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnDellInc.:bvrA01:bd11/11/2013:svnDellInc.:pnXPS139333:pvr:rvnDellInc.:rn0GFTRT:rvrA00:cvnDellInc.:ct8:cvr0.1:
dmi.product.name: XPS13 9333
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this recently start happening after an update or upgrade, or has it always happened in Trusty?

[Steve Magoun (smagoun)]

@Joseph - it did happen once when I was running 12.04 with a 3.5 lts-hwe kernel. I don't have data/logs from that incident. I have seen it twice since upgrading to trusty. Both incidents were in the last 2 weeks (since March 1).

[Joseph Salisbury (jsalisbury)]

Do you have an easy way to reproduce the issue? If so, we can perform a kernel bisect to identify the commit that introduced the bug.

Also, it would be good to know if the issue also happens with the latest mainline kernel, or if it's already been fixed there. It can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc6-trusty/

[Joseph Salisbury (jsalisbury)]

Looks like there is an issue during the freeze:

[92457.421160] usb 2-6: reset full-speed USB device number 24 using xhci_hcd
[92462.425009] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
[92462.629280] usb 2-6: Device not responding to set address.
[92462.833374] usb 2-6: device not accepting address 24, error -71
[92462.945452] usb 2-6: reset full-speed USB device number 24 using xhci_hcd
[92467.949443] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
[92468.153780] usb 2-6: Device not responding to set address.
[92468.357814] usb 2-6: device not accepting address 24, error -71
[92468.470010] usb 2-6: reset full-speed USB device number 24 using xhci_hcd
[92473.473935] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
[92473.678207] usb 2-6: Device not responding to set address.
[92473.882303] usb 2-6: device not accepting address 24, error -71
[92473.994403] usb 2-6: reset full-speed USB device number 24 using xhci_hcd
[92478.998472] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
[92479.202716] usb 2-6: Device not responding to set address.
[92479.406726] usb 2-6: device not accepting address 24, error -71
[92479.406827] usb 2-6: USB disconnect, device number 24
[92479.407920] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800a36c5000
[92479.407926] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800a36c5040
[92479.407931] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800a36c5080
[92479.407935] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800b8279600
[92479.407939] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800b8279640
[92479.489554] PM: Syncing filesystems ... done.
[92479.497183] PM: Preparing system for mem sleep
[92479.497453] Freezing user space processes ... (elapsed 0.001 seconds) done.
[92479.522865] usb 2-6: new full-speed USB device number 26 using xhci_hcd
[92484.526861] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
[92484.731193] usb 2-6: Device not responding to set address.
[92484.935186] usb 2-6: device not accepting address 26, error -71
[92485.047294] usb 2-6: new full-speed USB device number 27 using xhci_hcd
[92490.051312] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
[92490.255635] usb 2-6: Device not responding to set address.
[92490.459627] usb 2-6: device not accepting address 27, error -71
[92490.571742] usb 2-6: new full-speed USB device number 28 using xhci_hcd
[92495.575773] xhci_hcd 0000:00:14.0: Timeout while waiting for address device command

[Joseph Salisbury (jsalisbury)]

Steve, do you think this issue is related to bug 1218973 and bug 1265885 ?

[Steve Magoun (smagoun)]

@Joseph: I don't know, but I suppose it's possible. After reporting this bug, I blacklisted the i2c-hid driver to work around bug 1218973. I haven't done many S3 cycles since adding the blacklist, but I will pay attention to whether this USB bus failure happens again with i2c-hid blacklisted.

Note that when the USB subsystem fails, the touchpad functionality is not affected and the keyboard still works fine.

[Joseph Salisbury (jsalisbury)]

Thanks for the feedback, Steve.

Also, it would be good to know if the issue also happens with the latest mainline kernel, or if it's already been fixed there.

If you have a chance to test it, it can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc7-trusty/

[Guus Geluk (onsitecd)]

I have the same problem here after a fresh install of Ubuntu 14.04. When I suspend I can still wake up de computer with my USB mouse or keyboard, but they no longer function correctly. For instance the mouse cursor will still move but clicking no longer works. I can wake up with the keyboard but then it stops working. USB memory stick also seems frozen. Reconnecting devices does not help. My keyboard lights up briefly but that is all. The mouse completely stops working after reconnect.

On another partition I first did an upgrade from 13.10 to 14.04. Suspend works fine here. I did a fresh install on another partition bescause it would not boot. After the new install the grub menu was updated and it works fine now. But then I noticed the suspend problem on the fresh install.

[Joseph Salisbury (jsalisbury)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

  With the recent release of this Ubuntu release, would like to confirm if this bug is still present. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[psnizek (psnizek-i)]

Ubuntu 14.04, 3.13.0-30-generic on a Phenom-II 4 core desktop PC.

Problem description:
Wake-up after suspend: no keyboard, no mouse (both USB).

Workaround:
Unplug the devices and plug it in again.
Both, mouse and keyboard work again. I can login and work.

[Guus Geluk (onsitecd)]

confirmed, still exists after sudo apt-get dist-upgrade. All USB devices stop working, but I noticed also internet cable connection stopped working. so it is even broader then USB. Reconnecting devices does not help!

[Guus Geluk (onsitecd)]

Problem seems related to Nouveau drivers.
After installing Nvidea binary drivers the problem was fixed.

So still exists for nouveau drivers

[Alexandre Cavaco (alexcavaco)]

Ubuntu 14.04, 3.13.0-37-generic, 64-bits.
My system is an Asus motherboard (Sabertooth Z77), i5-3570K CPU and 16GB of RAM.

Problem:
Only my keyboard if affected after suspend/resume. Both my mouse and external soundcard (USB connected) work fine.
After suspend and resume, my keyboard rate is much slower and misses keystrokes if I type too fast.

Workaround:
My workaround is either: 1) Unplug the keyboard and connect it again or, 2) Remove module 'usbhid' and reinsert it again.

As a note I've got Nvidia binary drivers installed, and I even purged Nouveau and the problem continues, so I guess it isn't Noveau.

[joel (joel-brower)]

I have the same bug showing up on 14.04, i am on a compaq presario cq 56 laptop, my keyboard does work after resume from suspend. I am using an external logitec keyboard, but my microsoft optical wheel mouse does not function correctly. The red optical light is present, but only lit up dimly, and never brightens up to full brightness like it would normally, and appears to have a mild flicker to the light. It does not light up further like it would when returning from suspend and functioning correctly.

[joel (joel-brower)]

I don't know if this will reproduce it reliably yet or not, but when my laptop went to sleep in a seperate tty not on the window manager i unplugged/replugged, and it functioned on the tty again, but when changing back to the window manager , it instantly went back to the way it was. after another unplug/replug it resumed normal function again

[Zach (z-buildrocks)]

I have the same/similar bug with my mouse and wireless dongle, though I am running the most up-to-date Nvidia drivers, not the Noveau drivers. My mouse has lights which turn on fine, and a different mouse I have tested with works after resume.

[Yuriy Vidineev (adeptg)]

Dell XPS 13 9333. Tested linux-image-4.1.0-040100rc2-generic. The same issue. Interesting in syslog:

May 7 16:18:29 adept-XPS13 kernel: [ 177.255581] hub 2-1:1.0: hub_port_status failed (err = -71)
May 7 16:18:29 adept-XPS13 kernel: [ 180.034509] dell_wmi: Unknown key e00e pressed
May 7 16:18:29 adept-XPS13 kernel: [ 182.256180] hub 2-1:1.0: hub_port_status failed (err = -110)
May 7 16:18:29 adept-XPS13 kernel: [ 198.285350] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
May 7 16:18:29 adept-XPS13 kernel: [ 198.285352] xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
May 7 16:18:29 adept-XPS13 kernel: [ 198.285377] xhci_hcd 0000:00:14.0: HC died; cleaning up
May 7 16:18:29 adept-XPS13 kernel: [ 198.285403] dpm_run_callback(): usb_dev_resume+0x0/0x20 returns -22
May 7 16:18:29 adept-XPS13 kernel: [ 198.285422] PM: Device 2-1.3 failed to resume async: error -22
May 7 16:18:29 adept-XPS13 kernel: [ 198.285484] PM: resume of devices complete after 22081.908 msecs
May 7 16:18:29 adept-XPS13 kernel: [ 198.285784] PM: Finishing wakeup.
May 7 16:18:29 adept-XPS13 kernel: [ 198.285786] Restarting tasks ...
May 7 16:18:29 adept-XPS13 kernel: [ 198.285827] usb 2-1: USB disconnect, device number 2
May 7 16:18:29 adept-XPS13 kernel: [ 198.285845] usb 2-1.3: USB disconnect, device number 3
May 7 16:18:29 adept-XPS13 kernel: [ 198.286237] pci_bus 0000:01: Allocating resources
May 7 16:18:29 adept-XPS13 kernel: [ 198.286256] pci_bus 0000:02: Allocating resources
May 7 16:18:29 adept-XPS13 kernel: [ 198.286281] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
May 7 16:18:29 adept-XPS13 kernel: [ 198.286648] pci_bus 0000:01: Allocating resources
May 7 16:18:29 adept-XPS13 kernel: [ 198.286666] pci_bus 0000:02: Allocating resources
May 7 16:18:29 adept-XPS13 kernel: [ 198.286691] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment

[Yuriy Vidineev (adeptg)]

The same problem with fresh 3.13.0-53

[aleandro (aleandrodasilva)]

Same here with 3.13.0-55. Affected are the three usb ports.

[René (rene-boettcher)]

Same or similar problem here (Dell Precision 7810 workstation), the PC can still be awoken from suspend by USB input after a couple of hours, but if I return to it after the weekend, the machine is frozen (no USB, no network) and I have to do a hard reboot to access.

This started happening after I switched to fglrx-updates, so I will switch back to xorg ATI drivers and report back

[René (rene-boettcher)]

Problem still remains and now even occurred when leaving the machine over night. Network connection worked, so I could restart remotely. Current fix: deactivated screen lock :/

[rbhkamal (rbhkamal)]

I was surprised that actually disabling the screen lock fixes the problem, but it does. I bought a laptop from system76 it came preloaded with 15.10 64bit. Sometimes after resume, the mouse and keyboard would not be usable. Sometimes that happens on a fresh power up.

I noticed that sometimes it also fails to enter suspend, could be root cause of why USB stops working after the machine is resumed. See attached for USB errors.

[Evgenii Frolov (frol-onn)]

Have the same problem at Ubuntu-16.04 fresh install.
Kernel version is 4.4.0-31-generic #50-Ubuntu.
dmesg of the failing xhci port is attached.

Is there anything I can additionally do to help with this?

[Lucho Nacho (livalenz)]

This affects me, in Xubuntu 16.04, with Kernel 4.4.0-66-generic. it is just the port to which the mouse was connected before suspension that becomes disabled after resuming session.

[Val (pubalapoub)]

Linux Mint 18.1 (kernel 4.4.0-72-generic) here.
My case is very similar to the one described by Lucho Nacho.
My mouse is plugged to the 1st USB port (out of 3).
When resuming from 'suspend to RAM', this very USB port 'dies' (until I reboot my PC that is).
Then plugging in my mouse to the 2nd or 3rd port works around the issue (while the 1st port is still 'dead').
Suspending and resuming my PC again (with no reboot in between) doesn't generate the issue: the 2nd and 3rd ports are still usable normally (while the 1st one is still 'dead').
Some technical details are attached in file "Bus 003 Device 001.txt".

[Kai-Heng Feng (kaihengfeng)]

@Lucho Nacho, @Val

Please follow Joseph's instruction but use http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc6/ instead.

[Val (pubalapoub)]

Thanks Kai. Do you refer to comment #10?
Unfortunately this test won't be possible for me, this notebook was lent to me to eradicate a corrupted Win8 installation (job done - Linux installed) and I'll soon have to return it to its owner. I prefer to keep a clean fresh install (even if currently impacted by this bug) than risking to break more things due to my inexperience with manual kernel installations. This has been my most difficult Linux installation so far (for other reasons), so I'll leave it here, sorry. I hope someone else has the knowledge and time to test this v4.11-rc6.

[Christophe H (chrissc-humbert)]

Hello

Upgraded 17.04 and it is corrected for me :)

[Tarek Loubani (tareko)]

Adding the following to `/etc/pm/sleep.d/20_custom-xhci_hcd` worked for me:

```
#!/bin/sh
# File: "/etc/pm/sleep.d/20_custom-xhci_hcd".

case "${1}" in
  hibernate|suspend)
    # Unbind xhci_hcd devices
    echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
  ;;
  resume|thaw)
    # Bind xhci_hcd devices
    echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
  ;;
esac
```

[Tarek Loubani (tareko)]

p.s., This bug was true for me in xubuntu 16.04 and 18.04 on a Lenovo S20-30

[Kai-Heng Feng (kaihengfeng)]

@Tarek

It's a pretty bad workaround. Please file a new bug so we can check full dmesg.

[Mauro Sassi (maurosassi82)]

Same bug affects me on dell Latitude E7450 on freshly installed Bionic 18.04.1. Kernel 4.15.0-29-generic.

- After suspend/resume newly inserted USB devices are not detected and not listed by lsusb.
- Repeating suspend/resume with the device still inserted in the port solves the problem. At this point devices can be remove and inserted again and everything works as supposed.

I attached a dmesg output.

[Mauro Sassi (maurosassi82)]

Bug seems fixed for Bionic 18.04 in upstream 4.19.0-041900rc4-generic kernel

[adihezral (hezral)]

Hi, i'm not sure if this is same bug or not but symptom is similar. I managed to get it working but wasn't sure which actually made it worked but now it stopped working again.
I have a Dell Latitude E7250 and i boot into the 18.04 based elementaryOS from usb, so after resume the filesystem becomes read-only and i can't save the dmesg output.

What i've done
1. Added #32 workaround
2. Added udev rules to set power/control for my usb device to auto.
3. Enabled USB Powershare in the bios (not sure this was the one but the issue was gone after i set this after the above 2, 2 days later issue came back)
4. Set usbcore.autosuspend=-1 in grub
5. Upgrade to 4.19LTS

Symptom:
1. On AC: suspend/resume works perfectly
2. On Battery: if resume from suspend while AC succeded, the second resume while on Battery works but the subsequent suspend/resume fails in system read-only again.
3. On Battery: suspend/resume does not work resulting in system read-only.

I've been trying to reproduce my earlier success but to no avail.
Even a fresh install, the system will become read-only
Right now, suspend/resume only works on AC which leads me to suspect the USB hub/device is making this fail.

p/s sorry if i'm not following the right bug reporting etiquettes. i've done a lot of searching and tried multiple solutions but still can't fix this. Any help would be greatly appreciated and i will provide any help i can.