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.sh...@linux.intel.com> 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. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
