On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold <johan@xxxxxxxxxx> wrote: > Hi Mathias and Benjamin, > > Mathias, I understand you've got quite a lot on your plate with xhci at > the moment, but have you had a change to look at this issue yet? It's an > xhci-issue (possibly due to buggy hw) which seems related to the > non-superspeed enumeration work that was made by Sarah and Dan during > the fall. > > In summary, the device works fine with ehci, but fails to enumerate > with xhci. Prior to 3.14 this resulted in babble errors, but since 3.14 > it appears that enumeration times out instead: > > xhci_hcd 0000:00:14.0: Timeout while waiting for setup address command > > Sometimes it enumerates successfully with 3.14, though. > > Not sure if it's related, but Benjamin was also able to trigger: > > xhci_hcd 0000:00:14.0: HC died; cleaning up > > The full thread is available here: > > http://marc.info/?l=linux-usb&m=139464536212863&w=2 > > (The usb-serial related bits are really just about recognising the > VID/PID and is unrelated to the xhci-enumeration problem.) > > Do you need any further information from Benjamin? > > On Fri, Mar 21, 2014 at 04:18:54PM +0100, Johan Hovold wrote: >> On Thu, Mar 20, 2014 at 01:52:16PM -0700, Benjamin West wrote: >> > On Tue, Mar 18, 2014 at 1:10 AM, Johan Hovold <johan@xxxxxxxxxx> wrote: >> > > On Mon, Mar 17, 2014 at 11:58:57PM -0700, Benjamin West wrote: >> > >> On Mon, Mar 17, 2014 at 11:40 AM, Johan Hovold <johan@xxxxxxxxxx> wrote: > >> > Just speculating, git log -SNEW_SCHEME yields >> > 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72, it looks similar to the >> > other interesting patches. >> >> Yes, that is the commit I had in mind when I speculated that the problem >> might already have been fixed in v3.14-rc above. >> >> And indeed, without having looked to closely at this, it seems to at >> least have improved things as you no longer get the BABBLE error and >> actually manage to enumerate occasionally. >> >> <snip> >> >> > > Just to make sure this isn't a new regression in usb-next you're >> > > hitting, can you try applying the patch directly to v3.14-rc7? >> >> <snip> >> >> > Some mixed results: >> > I tested your carelink branch many more times. For some reason, it >> > started enumerating consistently for awhile, failed once, and then >> > enumerated consistently until I gave up. >> > >> > I cherry-picked your e2c7df19e2734f5d54d0d942a57d1018539e02c4 >> > on 3.14-rc7, which applied cleanly. Your changes work as expected here. >> > >> > The carelink usb stick did enumerate once or twice, here is a log: >> > https://gist.github.com/bewest/6488955#file-example-3-14-0-rc7-working-log >> > >> > I still often get failure to enumerate after inserting the usb stick: >> > I didn't keep an exact count, but this feels like a more consistent >> > failure somehow. >> > Recorded here: https://gist.githubusercontent.com/bewest/6488955/raw/213a79af21735e8822e00d8afa05abd63ffd67ee/syslog.log >> > >> > Mar 20 00:22:34 patient logger: Linux patient >> > 3.14.0-rc7-bewest-test-3.14-rc7-carelink-01 #6 SMP Wed Mar 19 21:12:24 >> > PDT 2014 x86_64 x86_64 x86_64 GNU/Linux >> > Mar 20 00:22:40 patient kernel: [ 615.054659] usb 3-2: new full-speed >> > USB device number 41 using xhci_hcd >> > Mar 20 00:22:45 patient kernel: [ 620.167319] xhci_hcd 0000:00:14.0: >> > Timeout while waiting for setup address command >> > Mar 20 00:22:50 patient kernel: [ 625.372047] xhci_hcd 0000:00:14.0: >> > Timeout while waiting for setup address command >> > Mar 20 00:22:50 patient kernel: [ 625.576031] usb 3-2: device not >> > accepting address 41, error -62 >> > Mar 20 00:22:50 patient kernel: [ 625.688157] usb 3-2: new full-speed >> > USB device number 42 using xhci_hcd >> > Mar 20 00:23:06 patient kernel: [ 640.802272] usb 3-2: device >> > descriptor read/64, error -110 >> > Mar 20 00:23:06 patient kernel: [ 640.906255] xhci_hcd 0000:00:14.0: >> > Setup ERROR: setup context command for slot 11. >> > Mar 20 00:23:06 patient kernel: [ 641.018244] usb 3-2: new full-speed >> > USB device number 43 using xhci_hcd >> > Mar 20 00:23:11 patient kernel: [ 646.018888] xhci_hcd 0000:00:14.0: >> > Timeout while waiting for setup address command >> > Mar 20 00:23:16 patient kernel: [ 651.223619] xhci_hcd 0000:00:14.0: >> > Timeout while waiting for setup address command >> > Mar 20 00:23:16 patient kernel: [ 651.427649] usb 3-2: device not >> > accepting address 43, error -62 >> > Mar 20 00:23:16 patient kernel: [ 651.539702] usb 3-2: new full-speed >> > USB device number 44 using xhci_hcd >> > Mar 20 00:23:21 patient kernel: [ 656.540344] xhci_hcd 0000:00:14.0: >> > Timeout while waiting for setup address command >> > Mar 20 00:23:27 patient kernel: [ 661.745070] xhci_hcd 0000:00:14.0: >> > Timeout while waiting for setup address command >> > Mar 20 00:23:27 patient kernel: [ 661.949103] usb 3-2: device not >> > accepting address 44, error -62 >> > Mar 20 00:23:27 patient kernel: [ 661.949163] hub 3-0:1.0: unable to >> > enumerate USB device on port 2 >> > Mar 20 00:24:06 patient whoopsie[1220]: online >> >> 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? 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. 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? > > Thanks, > Johan 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. Thanks for following up on this, -bewest -- 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
