Hi, I'm temporary back from vacation, for a week or two. On 08.07.2015 05:38, James Ralston wrote: > 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'm not aware of any AMD APU /ASUSTek xHCI issues, so a full-blown bug report would be appreciated. > 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. Does 4.1 work any better? > > 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 > does disabling runtime suspend for xhci make a difference?, something like: "echo on > /sys/bus/pci/devices/0000:00:14.0/power/control" Looks like runtime pm tries to suspend xhci, but fails as xhci is busy, and after this we fail to read the device descriptors with -EPROTO) > 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 > So when unplugging a device xhci fails to finish a command on the command ring. The command timer times out, we try to stop the command ring to skip/remove the "faulty" command, but stopping the command ring fails so we assume xhci is completely messed up. Now we just need to figure out why this happends. > 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. > consensus is that xhci should work without issues on AMD APU chipsets Thanks -Mathias -- 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
