Attempting to use the Valve Index HMD breaks the USB controller it is connected into - any newly connected or reconnected devices aren't being recognized by the system. Unplugging the Index doesn't solve the issue, but rebooting the system does. After encountering this issue, during system shutdown I get the following error: "usb 1-9: device descriptor read/64, error -110". I verified that usb 1-9 is indeed one of the HMD's connections. Note that only the controller the HMD is connected into breaks, the rest keeps working as intended.
I have the same problem. The Valve Index HMD uses the xhci_hmd driver for a USB 3 connection. The culprit shows usually in dmesg as: [77865.729313] xhci_hcd 0000:08:00.0: xHCI host not responding to stop endpoint command. [77865.729989] xhci_hcd 0000:08:00.0: xHCI host controller not responding, assume dead [77865.729995] xhci_hcd 0000:08:00.0: HC died; cleaning up After which obviously no new connections can be made anymore. I compiled vanilla 5.6.0-rc7 with >grep XHCI .config CONFIG_USB_XHCI_HCD=m CONFIG_USB_XHCI_DBGCAP=y CONFIG_USB_XHCI_PCI=m # CONFIG_USB_XHCI_PLATFORM is not set reloading the xhci_pci module restores the controller. If someone has patches to try out then I can apply them and test it out. If any other info is needed please ask!
I had a LOT more problems with the USB 3 on my ASUS Sabertooth 990FX motherboard, so I bought a PCI Express card (PEXUSB3S44V from Startech, see https://www.startech.com/nl/en/Cards-Adapters/USB-3.0/Cards/PCI-Express-USB-3-Card-4-Dedicated-Channels-4-Port~PEXUSB3S44V) basically because it is the most expensive card you can get (I was hoping to rule out certain things with that). As a result I no longer needed to disable iommu in the BIOS or pass iommu=soft as kernel boot parameter. But the above bug remained (although less frequently). The PEXUSB3S44V uses the μPD720202 host controller chip (four of them I think). Documents here https://www.renesas.com/us/en/products/usb-assp/upd720202.html#documents This bug has the feel of https://bugzilla.kernel.org/show_bug.cgi?id=65021 from 2013 (kernel 3.x). A patch that has been in the kernel for long related to that bug is https://www.spinics.net/lists/linux-usb/msg122678.html a few people said was fixing the issue for them. However, I added debug output to the module and in my case it never even gets to the line > xhci->quirks |= XHCI_AVOID_BEI; so no wonder that patch didn't solve it for me ;). Hence, apparently pdev->vendor != PCI_VENDOR_ID_INTEL for me. But maybe it should be? The μPD720202 specs say it is Intel compatible...
Not sure if what I said is correct. I was referring to: From the "User's Manual: Hardware" of the μPD720202: 1. Overview The μPD720201 and μPD720202 are Renesas’ third generation Universal Serial Bus 3.0 host controllers, which comply with Universal Serial Bus 3.0 Specification, and Intel’s eXtensible Host Controller Interface (xHCI). These devices reduce power consumption and offer a smaller package footprint making them ideal for designers who wish to add the USB3.0 interface to mobile computing devices such as laptops and notebook computers.
The commit comments might be relevant / interesting too: https://github.com/torvalds/linux/commit/227a4fd801c8a9fa2c4700ab98ec1aec06e3b44d So again, if this affects me (the μPD720202) then that patch has no effect because that code is never executed.