(Resubmitting w/ no HTML) Hello, I'm working on a bug we have on one of our newer platforms. This is the first platform we're supporting that uses USB 3.0, and we're finding that if we boot the device with a USB keyboard/mouse inserted into one of the USB 3.0 ports the xhci driver will fail to initialize and deregister the 3.0 bus. You can only get keyboard/mouse back by either modprobing xhci or inserting the device into a 2.0 port. Our system an x86 system based on Ubuntu Lucid 10.04 (kernel 2.6.32-33-generic). I've tried this out with the latest 3.0 kernel from Ubuntu oneiric and the results are the same. After reviewing the code I've traced the issue down to the following code chain: 1) In core/hcd.c, usb_add_hcd() attempts to reset/initialize the xhci controller via hcd->driver->reset(hcd) 2) This calls host/xhci-pci.c, xhci_pci_setup(), which attempts to an xhci_halt(). 3) This calls host/xhci-hcd.c, xhci_halt(), which calls handshake(), which returns -ETIMEDOUT 4) This gets passed back down via return errors to usb_add_hcd(), which refuses to initialize the controller and deregisters the bus If I just break the return chain by not returning/erroring out if xhci_halt() fails in xhci_pci_setup() then everything appears to work fine, xhci loads, the bus shows up in lsusb, keyboard/mouse works fine. Some additional test results that may be useful: 1) Occurs with standard HP USB keyboard 2) Occurs with standard HP USB mouse 3) Occurs with iogear wireless multimedia USB keyboard: http://www.iogear.com/product/GKM561R/ 4) Does NOT occur with ADATA 16gb USB 3.0 USB flash drive 5) Does NOT occur with Logitech ClearChat Comfort USB headset: http://www.amazon.com/Logitech-ClearChat-Comfort-Headset-Black/dp/B000UXZQ42 6) Inserting the keyboard/mouse after boot (e.g. xhci is already initialized) does not cause the issue 7) Upgrading to latest 3.0 kernel does not fix the issue 8) Increasing the handshake timeout value dramatically (from 16 cycles to 1000) does not resolve the issue 9) Ignoring the ETIMEDOUT returned by xhci_halt does resolve the issue 10) Insert into USB 2.0 port, interrupt boot w/ grub prompt, then switching to USB 3.0 port and booting kernel does NOT cause the issue (e.g. if BIOS does not initialize the device the issue does not occur) I've attached the output of dmesg for a bad run and a good run, as well as a screencap of a visual diff of the two at the point where the xhci_halt error/bus deregister occurs. I believe the key difference is at line 963, where we see that HC is either running or halted before the xhci_pci_setup() is called. For the case where it is running, this is likely occurring due to the BIOS initializing the BUS/device before passing control to linux (see test case #10). My main question is, what is the safest method to resolve this issue? I can ignore the xhci_halt() if needed, but it seems like it would be better to understand why the halt/handshake times out if the bus/controller/device is already running, which is a bit more deeply involved than I'm comfortable with. Thanks! Fletcher -- 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
