Re: [GIT PULL] USB driver fixes for 3.18-rc7

[Mathias Nyman <mathias.nyman@intel.com>]

On 11.12.2014 20:47, Greg KH wrote:
> On Wed, Dec 03, 2014 at 06:02:08PM +0200, Mathias Nyman wrote:
>> On 02.12.2014 20:18, Greg KH wrote:
>>> On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote:
>>>> Hmm, Greg.
>>>>
>>>> I seem to get this problem possibly more commonly at boot these days:
>>>>
>>>>   usb 1-6: new full-speed USB device number 2 using xhci_hcd
>>>>   usb 1-6: device descriptor read/64, error -71
>>>>   xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
>>>>   usb 1-6: hub failed to enable device, error -22
>>>>   usb 1-6: new full-speed USB device number 3 using xhci_hcd
>>>>   usb 1-6: device descriptor read/64, error -71
>>>>   usb 1-6: hub failed to enable device, error -22
>>>>   usb 1-6: new full-speed USB device number 4 using xhci_hcd
>>>>   usb 1-6: Device not responding to setup address.
>>>>   usb 1-6: Device not responding to setup address.
>>>>   usb 1-6: device not accepting address 4, error -71
>>>>   usb 1-6: new full-speed USB device number 5 using xhci_hcd
>>>>   usb 1-6: Device not responding to setup address.
>>>>   usb 1-6: Device not responding to setup address.
>>>>   usb 1-6: device not accepting address 5, error -71
>>>>  usb usb1-port6: unable to enumerate USB device
>>>>
>>>> and my keyboard doesn't work. I then unplug and re-plug it, and get
>>>>
>>>>   usb 1-6: new full-speed USB device number 9 using xhci_hcd
>>>>   usb 1-6: New USB device found, idVendor=2516, idProduct=0020
>>>>   usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>>>>   usb 1-6: Product: Quickfire Rapid i
>>>>   usb 1-6: Manufacturer: CM Storm
>>>>
>>>> Any ideas? Some setup delay that isn't long enough at boot time for a
>>>> slightly finicky device? It has happened before, but now I've gotten
>>>> it twice within a couple of days:
>>>>
>>>>   Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>>>   Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>>>   Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>>>
>>>> (I've had this keyboard since mid-September, and looking at the logs
>>>> this machine has been rebooted 41 times since, with those three
>>>> failures..)
>>>
>>> I've been seeing this occasionally recently as well, but was blaming a
>>> "bad" USB 3 hub I have here that I use, and the problem goes away with a
>>> replug.
>>>
>>> Mathias, any ideas what is going on here?
>>>
>>
>> Looks like when xhci changed to use "new scheme" device enumeration for non
>> SuperSpeed devices, we broke the device descriptor read retry for xhci.
>>
>> Normally we try to read the descriptor again, and if it still fails then fall back
>> to old scheme. In this failing xhci case the slot is left in a default state after
>> first failed descriptor read, and we then try to enable the slot again in retry, 
>> which is an invalid xhci context state change, and prints the error message:
>>
>> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1
> 
> I see this all the time on my MinnowboardMax.  For slot 2 that is.
> 
> And on this machine, it does not boot from USB properly, I have to,
> after the kernel comes up (which was read off of USB by UEFI just fine),
> unplug and plug the storage device back in so that the boot process
> continues.
> 
> Works that way for 2 different USB 3.0 storage devices.
> 

I got a patch that should fix the xhci "Setup ERROR" part in a setup-error-fix branch:

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git setup-error-fix

It's based on Gregs usb-next tree. 
It doesn't solve why the first device descritor read fails.

>> After this It might be hard to get the device addressed. 
>>
>> I don't know why it fail the first device descriptor read, but fixing the xhci part
>> should allow more real reties. I'll work on it.
>>
>> The change to use xhci "new scheme" enumeration was done in 3.14 to support known
>> legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72
> 
> How can that break "non-legacy" devices?

It added a enable_device callback for all usb2 devices during enumeration, which
fails if called twice, or if the slot was already enabled in the xhci case.
Caused whole enumeration to be aborted.   

-Mathias