Before I submit a full-blown bug report, could anyone tell me whether there are already known issues with the xHCI driver on AMD and/or ASUSTek systems, specifically involving AMD APU chipsets? I have two different AMD systems, both using ASUSTek AMD motherboards: an A88XM-E (AMD A88X / Bolton D4 chipset), and an older F2A85-M PRO (AMD A85X FCH / Hudson D4 chipset). On both of these systems, under all Linux kernels up through 4.0.4, the USB 3.0 ports are broken to the point of being unusable. For starters, almost all high-speed USB 3.0 devices simply fail to work. On the A88X system (running Fedora 20 with kernel 4.0.4), here's what happens when I connect my LG G4 (not sure if first line is related, so I'm including it): [ 253.825901] pci_pm_runtime_suspend(): hcd_pci_runtime_suspend+0x0/0x50 returns -16 [ 254.028227] usb 3-2: new high-speed USB device number 2 using xhci_hcd [ 254.144879] usb 3-2: device descriptor read/all, error -71 [ 254.297946] usb 3-2: new high-speed USB device number 3 using xhci_hcd [ 254.413979] usb 3-2: device descriptor read/all, error -71 [ 254.566667] usb 3-2: new high-speed USB device number 4 using xhci_hcd [ 254.581420] usb 3-2: device descriptor read/all, error -71 [ 254.734489] usb 3-2: new high-speed USB device number 5 using xhci_hcd [ 254.748747] usb 3-2: device descriptor read/all, error -71 [ 254.748782] usb usb3-port2: unable to enumerate USB device In contrast, when I plug the LG G4 into my Intel-based laptop (running Fedora 22, also with the 4.0.4 kernel), it works perfectly: [165797.389963] usb 1-6: new high-speed USB device number 22 using xhci_hcd [165797.555755] usb 1-6: New USB device found, idVendor=1004, idProduct=633e [165797.555778] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [165797.555783] usb 1-6: Product: LGE Android Phone [165797.555786] usb 1-6: Manufacturer: LG Electronics Inc. [165797.555789] usb 1-6: SerialNumber: LGH811df5dac44 Same kernel (or reasonably so), same device, yet the AMD system craps the bed, and the Intel system works perfectly. Even worse, when I unplug *ANY* USB device on the AMD systems, the xhci_hcd driver dies about 90% of the time: [ 259.747143] xhci_hcd 0000:00:10.1: Stopped the command ring failed, maybe the host is dead [ 259.747188] xhci_hcd 0000:00:10.1: Host not halted after 16000 microseconds. [ 259.747195] xhci_hcd 0000:00:10.1: Abort command ring failed [ 259.747205] xhci_hcd 0000:00:10.1: HC died; cleaning up Again, in contrast, the Intel system works perfectly: [165873.817070] usb 1-6: USB disconnect, device number 22 I've seen various mutterings that on AMD systems, I need to enable the IOMMU in the BIOS / UEFI in order for USB devices to work correctly, and pass various iommu= flags on the kernel command line. But for all combinations of IOMMU settings I tried, the USB3 ports are still essentially broken. (Plus, if enable the IOMMU in the UEFI, the r8169 driver won't pass any traffic... but that's a different problem, sigh.) Both systems are/were dual-boot Windows 7 systems, and I had no issues with the USB3 ports working under Windows. So I doubt that faulty hardware is involved, unless the ASUSTek driver for Windows works around it. So, in summary, is this actually a known issue? E.g., "Yes, sorry, we're still working on xHCI support for the newer AMD APU chipsets and you're going to have a crappy time until support is further along; sorry." That would be disappointing if that's actually the case, because it would feel like 1995 again instead of 2015, but I can deal. But if the consensus is that xHCI should work without issues on AMD APU chipsets, then I'll go gather up the information to make a full bug report. I just don't want to waste everyone's time if there's already a known issue that I just wasn't able to find via web searches. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
