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 -- 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
