On Wed, Apr 23, 2014 at 11:12 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > On Wed, Apr 23, 2014 at 08:16:49AM +0800, Gavin Guo wrote: >> Hi Sarah, >> >> >> On Wed, Apr 23, 2014 at 7:57 AM, Sarah Sharp >> <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: >> > >> > [Adding Mathias, who is the xHCI driver maintainer as of 3.15.] >> > >> > On Wed, Apr 23, 2014 at 07:23:43AM +0800, Gavin Guo wrote: >> > > Hi Sarah, >> > > >> > > I found that in [AMD] FCH USB XHCI Controller [1022:7814]. The USB 3.0 disk >> > > can't work in SuperSpeed after several times of hotplug. I've tested many >> > > platforms having this XHCI controller [1022:7814] and found that some are >> > > easy to duplicate some are hard. >> > > >> > > The log is attached. Let me shortly explain how I tested the platform: >> > > >> > > I used the 3.13 kernel and built the xhci_hcd as modules with >> > > CONFIG_USB_DEBUG enabled. So, you will see a lot of messages in the booting >> > > process. Then, I disabled the debug by dynamic debug mechanism using the >> > > commands "echo '-p' > /sys/kernel/debug/dynamic_debugger/control" and >> > > enabled only the xhci_hcd by "echo 'module xhci_hcd +p' > >> > > /sys/kernel/debug/dynamic_debug/control." Finally, after 4 times of >> > > hotplug, you can see the line "5582 Apr 22 18:34:59 u-HP-xx-xxxxxxxx-PC >> > > kernel: [ 282.130270] usb 3-1: new high-speed USB device number 5 using >> > > xhci_hcd." The usb 3.0 disk is recognized as the high-speed. >> > >> > The xHCI hardware (host and device) link trains at either high speed or >> > SuperSpeed. Software has no control over that. It's possible that >> > there wasn't a good electrical connection at SuperSpeed, so the device >> > was recognized at high speed, and wasn't able to link train at >> > SuperSpeed when it was reset. >> > >> > I expect that some devices are better than others at link training. >> > Some host controllers have better link training PHYs than others, so I >> > would expect some host controllers to not be able to link train >> > occasionally. I also expect that changing the SuperSpeed cable might >> > make a difference. >> > >> > Basically, this is not a software problem, it's probably a hardware >> > issue. >> >> >> We found that removing the xhci_hcd module and doing insmod again can >> solve the problem. So, I'm thinking if it has the possibility to add >> the fix as quriks in the code. > > That only helps because unloading and reloading the driver resets the > host controller, which will cause the host to link train the port again. > In the meantime, you disconnect all your other devices, which may > include the USB hard drive with your boot partition. That would be > disastrous, and very user unfriendly. > > This is *not* the right fix, and I would not recommend Mathias take such > a quirk patch. Users with that particular USB device and host combo > will just have to deal with it occasionally coming up as a high speed > device. I'm really appreciated for your patient reply. Totally agree with your analysis. Thanks, Gavin Guo > > Sarah Sharp -- 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
