You are not logged in.
Since the upgrade to Linux 4.15, I'm experiencing an issue where all my USB devices just die seemingly without any cause. Both my laptop's internal (attached) keyboard as well as my external keyboard die.
Replugging the external keyboard unfortunately does not solve the problem. My touchpad, on the other hand, continues to work, though it may internally be connected via PS/2.
After this happens, I have only been able to solve it by rebooting.
In the logs, the following error can be found.
xhci_hcd 0000:3d:00.0: xHCI host controller not responding, assume deadThis issue has been posted on the Arch forums before, such as in this thread, but unfortunately the solution proposed there (adding intel_iommu=false to the kernel parameters) had no effect in my case, hence my repost.
Is there anyone else experiencing this issue or is there perhaps a way to kickstart xHCI again so that a reboot at least is not required?
For the moment I've downgraded to linux-lts, which is at version 4.14 and does not expose this issue. I've also tested the recently released 4.16, but it does not seem to fix the issue either. I'd be happy to post this on the kernel bug tracker if this appears to be a kernel bug or on the Arch bug tracker if necessary.
Thanks!
Offline
Can confirm, happening on 4.16 as well.
[ 173.513098] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 173.513108] xhci_hcd 0000:00:14.0: HC died; cleaning upSeems something is not right with xHCI(USB 3.0) handling after 4.14
Offline
Please post the full dmesg output from an affected boot.
Edit:
have you tried blacklisting xhci_pci or bisecting between 4.14 and 4.15?
Last edited by loqs (2018-04-27 14:18:59)
Offline
Thanks for your responses.
dmesg from an affected boot is a bit hard, since they seem to be replaced every boot and I would need to wait for the issue to occur again. However, I see that journalctl contains most of the same information, so I took the liberty of fetching the logs from one complete boot (start to shutdown) that contained the issue and placed it here.
I have also not tried bisecting yet, since I'm (unfortunately) on a work machine that I do not have the liberty of experimenting too much with and the issue doesn't always expose itself, so the breakage may significantly affect my work.
I've not yet tried blacklisting the xhci_pci driver. If this doesn't break my USB devices from working, so it is something I can try!
Offline
You can blacklist xhci-pci Using_kernel_command_line so that the option will not persist beyond a boot.
If you do lose USB devices then you can power cycle the machine to restore the original functionality.
Offline
Thanks for taking the time to respond.
Unfortunately, blacklisting xhci_pci breaks all my USB devices permanently, there does not appear to be any sort of fallback to something else - at least not automatically.
Offline
I can confirm the problem, please find an excerpt of my dmesg output below. The problem causes my bluetooth mouse to stop working at random times.
[ 0.713879] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 0.713886] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[ 0.714956] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x00109810
[ 0.714962] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[ 0.715082] usb usb1: Manufacturer: Linux 4.16.4-1-ARCH xhci-hcd
[ 0.718643] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 0.718647] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[ 0.718686] usb usb2: Manufacturer: Linux 4.16.4-1-ARCH xhci-hcd
[ 1.046752] usb 1-5: new high-speed USB device number 2 using xhci_hcd
[ 1.320021] usb 1-7: new full-speed USB device number 3 using xhci_hcd
[ 5265.105807] xhci_hcd 0000:00:14.0: xHC is not running.
[ 5265.111852] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 5265.111868] xhci_hcd 0000:00:14.0: HC died; cleaning upI tried several workarounds that I found on the web with no avail:
1. Setting the kernel parameters iommu=soft pci=nomsi as suggested here: https://bugs.launchpad.net/ubuntu/+sour … ug/1413440
2. Setting the kernel parameter intel_iommu=off as suggested here: https://bbs.archlinux.org/viewtopic.php?id=230764
3. Some source suggested that adding options iwlwifi bt_coex_active=0 to /etc/modprobe.d/iwlwifi.conf might fix it (can't found source anymore).
Restarting xHCI sometimes works for me like so (but sometimes it does not work for no apparent reason):
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
sleep 5
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bindI'd be interested in learning the reason and even a fix to this problem. Thanks.
Offline
I think this is more likely to do with power management. You may wish to look at either disabling USB autosuspend or blacklisting the relevant devices.
I'm using TLP for power management which makes either process quite easy, though may also be the cause.
Offline
I do indeed have powertop enabled with --auto-tune. I'll try removing the xHCI devices from the tuning and see if this makes any difference.
Offline
I turned USB_BLACKLIST_BTUSB on (i.e. disabled USB autosuspend for Bluetooth devices) via TLP and until now the problem did not show again.
Offline
Just wanted to mention that the problem has not shown itself again after I disabled USB suspend for my xHCI controllers. This does seem to indicate that there is some sort of bug in USB power management from kernel 4.15 upwards.
What is the right course of action to proceed? Shall I report this issue to the Arch bug tracker or to the kernel mailing list?
Offline
What is the right course of action to proceed? Shall I report this issue to the Arch bug tracker or to the kernel mailing list?
http://www.linux-usb.org/mailing.html
https://www.kernel.org/doc/html/latest/ … -bugs.html
Nothing will happen if you report it on the Arch bug tracker without already having a fix to apply.
Offline
Okay, thanks. I've reported an issue to the kernel bug tracker here.
Offline
perl scripts/get_maintainer.pl drivers/usb/host/xhci.c
Mathias Nyman <mathias.nyman@intel.com> (supporter:USB XHCI DRIVER)
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:USB SUBSYSTEM)
linux-usb@vger.kernel.org (open list:USB XHCI DRIVER)
linux-kernel@vger.kernel.org (open list)Supported kernel versions are listed on https://www.kernel.org/ excluding those marked EOL
Offline
This was also posted to the USB mailing list as requested, see also [1]. Apparently there is a related issue as well [2].
[1] https://marc.info/?l=linux-usb&m=152605665812321&w=2
[2] https://marc.info/?l=linux-usb&m=152335174903017&w=2
Offline
@mwohah you need any help building the kernel with the suggested patch applied or building git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git for-usb-linus ?
Offline
@loqs I'll give it a whirl via the wiki first, but if I have any questions, I'll let you know - thanks for the offer, in any case!
I also wanted to let others know that there is a patch available for testing in the linked mailing list topic. I'll try and take it out for a test drive, but will be away for the coming two weeks (poor planning, I know). In any case, the more testers, the merrier!
Offline
I'm still running into this issue on the 4.16.12 kernel, even though the issue was supposedly fixed:
https://lwn.net/Articles/755716/
Mathias Nyman (2):
xhci: zero usb device slot_id member when disabling and freeing a xhci slot
xhci: Show what USB release number the xHC supports from protocol capablity
Anyone still having issues? Also I was curious whether this was only affecting usb2 or usb3 xhci devices, or both. I'm testing out just disabling one at a time in powertop.
Offline
@anon_archuser issue is ongoing see https://marc.info/?l=linux-usb&m=152543465517329&w=2
Offline
@anon_archuser issue is ongoing see https://marc.info/?l=linux-usb&m=152543465517329&w=2
Ahh, looks like the patch is in review limbo here: https://marc.info/?l=linux-usb&m=152544392822763&w=2
Last edited by anon_archuser (2018-05-29 17:33:25)
Offline
Hi, I am having similar issues. But only similar.
Mainly with that Renesas uPD720202 USB 3.0 as an expresscard in a laptop.
In Kernel 4.16.9 it started working again, but totally stopped showing the smartctl smart values with the Maxtor M3 I'm using.
In the actual kernel 4.16.11 it stopped working again.
Still no SMART values, even on the USB 2.0 ports
Offline
I'm running into the same issue, but on Ubuntu 18.04. Linux x1c6 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
I'm interested in a work around to avoid having to reboot my computer if one exits. Otherwise I'll follow along & wait till this issue is actually resolved.
Offline
I'm running into the same issue, but on Ubuntu 18.04. Linux x1c6 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
I'm interested in a work around to avoid having to reboot my computer if one exits. Otherwise I'll follow along & wait till this issue is actually resolved.
echo 'on' > '/sys/bus/usb/devices/usb2/power/control';Last edited by anon_archuser (2018-05-31 12:53:07)
Offline
I can confirm the problem, please find an excerpt of my dmesg output below. The problem causes my bluetooth mouse to stop working at random times.
[ 0.713879] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 0.713886] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 0.714956] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x00109810 [ 0.714962] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported [ 0.715082] usb usb1: Manufacturer: Linux 4.16.4-1-ARCH xhci-hcd [ 0.718643] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 0.718647] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 [ 0.718686] usb usb2: Manufacturer: Linux 4.16.4-1-ARCH xhci-hcd [ 1.046752] usb 1-5: new high-speed USB device number 2 using xhci_hcd [ 1.320021] usb 1-7: new full-speed USB device number 3 using xhci_hcd [ 5265.105807] xhci_hcd 0000:00:14.0: xHC is not running. [ 5265.111852] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead [ 5265.111868] xhci_hcd 0000:00:14.0: HC died; cleaning upI tried several workarounds that I found on the web with no avail:
1. Setting the kernel parameters iommu=soft pci=nomsi as suggested here: https://bugs.launchpad.net/ubuntu/+sour … ug/1413440
2. Setting the kernel parameter intel_iommu=off as suggested here: https://bbs.archlinux.org/viewtopic.php?id=230764
3. Some source suggested that adding options iwlwifi bt_coex_active=0 to /etc/modprobe.d/iwlwifi.conf might fix it (can't found source anymore).Restarting xHCI sometimes works for me like so (but sometimes it does not work for no apparent reason):
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind sleep 5 echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bindI'd be interested in learning the reason and even a fix to this problem. Thanks.
Thanks.This worked for me.
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
sleep 5
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bindOffline
I am seeing the same issue on my matebook D14 laptop with an Intel 8265 WiFi/BT card.
BT part disappears after a while.
The unbind/bind workaround is not acceptable for me as it happens after a few minutes.
Offline