On Tue, Feb 08, 2011 at 07:14:31PM -0800, Luben Tuikov wrote: > The hw setup: NEC based controller, device directly attached to the embedded hub. Is this an embedded USB 3.0 hub? Because we don't currently support USB 3.0 hubs. > The device is reset via libusb_reset_device(). The xHCI driver has to go through a special process to let the hardware know the device has been reset. I've modified the usbcore reset methods to use that, but if usbfs is falling on a slightly different code path than the usb core code, then it's probably missing that call into the xHCI driver. Please file a bug on bugzilla, as I'm completely swamped right now, and I don't want to lose this bug report. > The kernel log (master is at f878133, dynamic debug enabled for xhci and usbcore), shows this: > > Feb 8 16:35:33 localhost kernel: usb 9-2: reset SuperSpeed USB device using xhci_hcd and address 16 > Feb 8 16:35:33 localhost kernel: xhci_hcd 0000:03:00.0: WARN: short transfer on control ep > Feb 8 16:35:33 localhost kernel: usb 9-2: config index 0, error 27 > Feb 8 16:35:33 localhost kernel: usb 9-2: device firmware changed > Feb 8 16:35:33 localhost kernel: hub 9-0:1.0: logical disconnect on port 2 > Feb 8 16:35:33 localhost kernel: hub 9-0:1.0: state 7 ports 4 chg 0004 evt 0000 > Feb 8 16:35:33 localhost kernel: hub 9-0:1.0: port 2, status 8103, change 0000, 5.0 Gb/s > Feb 8 16:35:33 localhost kernel: usb 9-2: USB disconnect, address 16 > Feb 8 16:35:33 localhost kernel: usb 9-2: unregistering device > Feb 8 16:35:33 localhost kernel: usb 9-2: unregistering interface 9-2:1.0 > Feb 8 16:35:33 localhost kernel: usb 9-2: unregistering interface 9-2:1.1 > Feb 8 16:35:33 localhost kernel: usb 9-2: usb_disable_device nuking all URBs > Feb 8 16:35:33 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:33 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:33 localhost kernel: usb 9-2: device not accepting address 17, error -71 > Feb 8 16:35:33 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:33 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:33 localhost kernel: usb 9-2: device not accepting address 18, error -71 > Feb 8 16:35:33 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:34 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:34 localhost kernel: usb 9-2: device not accepting address 19, error -71 > Feb 8 16:35:34 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:34 localhost kernel: usb 9-2: Device not responding to set address. > Feb 8 16:35:34 localhost kernel: usb 9-2: device not accepting address 20, error -71 > Feb 8 16:35:34 localhost kernel: hub 9-0:1.0: unable to enumerate USB device on port 2 > Feb 8 16:35:36 localhost kernel: hub 9-0:1.0: hub_suspend > Feb 8 16:35:36 localhost kernel: usb usb9: bus auto-suspend > > The USB bus trace shows: > 0) hot reset (TS1/2) > 1) SET ADDRESS to addr 0, new address 1. Now the device's got address 1. > 2,3) GET DESC device... > 4) GET CONFIG > 5) SET ADDRESS to addr 0, new address 1. <-- problem. > > In HS mode, the 2nd SET ADDRESS is not observed, unless of course > immediately after a bus reset, but not out of the blue like what's shown > above. Also the data packet shows that the "new address" is 1 and > not 18, 19, etc. as shown in the kernel log above. The xHCI hardware picks the new device address, not the USB core. Most hardware seems to issue the addresses sequentially, starting from 1. So if the only device on the system was reset, address 1 is free, and will probably be given to the device on the next Set Address xHCI command. The hardware-selected addresses could also be an issue with usbfs, since that requires special calls into the xHCI driver as well. > Anyone seen this (observed only in SS, HS is fine)? Is there a fix for > this in the trunk since f878133b? I have never tried to reset a USB device under xHCI via usbfs, so that's probably why it never showed up. Thanks for catching this. 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
