On Sun, Apr 13, 2014 at 05:04:50PM -0700, Benjamin West wrote: > On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold <johan@xxxxxxxxxx> wrote: > >> Ok, looks like the same error as with usb-next. Could you provide a log > >> with debugging enabled when enumeration fails on v3.14-rc7? Perhaps > >> someone who knows more about xhci could be kind enough provide some > >> further insight as to what might be going on then. > > > > Benjamin, did you look any further at this? > > I thought I had enabled debugging. > My boot config has > * CONFIG_USB_DEBUG=y > * CONFIG_USB_SERIAL_DEBUG=m > and several other relevant looking items set to y, perhaps I simply > need to dynamically enable debug by setting something in sysfs? Yes, dynamic debugging and echo module xhci_hcd +p >/sys/kernel/debug/dynamic_debug/control should do the trick. > I've been playing with this this (v3.14-rc7) extensively over the past > few weeks. > > * The first insert of the device rarely works, but occasionally it > does appear on boot > * usually lsusb blocks for a long time (10's of seconds) if the > enumeration is not working > > What I've found is that removing the usb stick while lsusb is hanging, > and re-inserting, on the third try the device enumerates. After this, > plugging in/removing enumerates as expected. Once the device > enumerates successfully, it seems to consistently enumerate > afterwards. > > Each port seems to experience this problem independently of the > others. Eg, plugging in the device 3 times on a port seems to make it > enumerate, but the first few times lsusb tends to hang for a long > time. I guess that points to the HC rather than the device then. > To test this, I just tried waiting the full length between timeouts. > There is a log of the result here: > https://gist.githubusercontent.com/bewest/6488955/raw/77a431e50ebadd27641e2685dc1184aa96da05c6/annotated-runs-3.14.0-rc7-bewest-test-3.14-rc7-carelink-01.log > > The procedure was to insert/remove the stick only after waiting for > the full timeout, eg, waiting for lsusb to return, and never > interrupting the process. > After several attempts, something happened, and the usb stack as a > whole seems to have reset or something, I lost access to my internal > bluetooth, and the Atheros entry usually present from lsusb output was missing. > > On reboot, I continued and kept the entire syslog from reboot | grep > kernel, here: > https://gist.githubusercontent.com/bewest/6488955/raw/c436764d806426d373c36b25d4eb96276a16c1ae/theory-grep-kernel-3.14.0-rc7-bewest-test-3.14-rc7-carelink-01.log > > In this one, I did not wait for lsusb to timeout; the number of > attempts doesn't seem to matter, but the timing does. This time I > seem to be able to moderate what happens by removing the usb stick > just after I see: > > Apr 13 15:51:16 patient kernel: [ 431.837705] xhci_hcd > 0000:00:14.0: Timeout while waiting for setup address command > > I'm doing "watch lsusb" in another terminal, and removing the device > as soon as I see this message, then inserting it again. I stop doing > the lsusb/syslog output indicates that the device has enumerated. > > > Benjamin, have you tried the device on a different host controller? > > > No, I haven't, my access to different machines is limited right now. > I have spares of this device, I'd be willing to mail one to someone > if it'd be helpful. I guess that would be Mathias or some other xhci-person. Johan -- 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
