On Wed, Apr 23, 2014 at 11:12 PM, Sarah Sharp
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
>> 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--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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html