Re: xhci: non-superspeed enumeration failure (was: Re: medtronic usb productId 0x8001: usbserial support, xhci enumeration)
On Sun, Apr 13, 2014 at 05:04:50PM -0700, Benjamin West wrote: On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold jo...@hovold.com 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 :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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci: non-superspeed enumeration failure
On Sun, Apr 13, 2014 at 05:53:10PM -0700, Benjamin West wrote: On Tue, Apr 8, 2014 at 12:52 AM, Johan Hovold jo...@hovold.com wrote: On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote: On 04/03/2014 07:32 PM, Johan Hovold 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 :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 :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=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? It might be related to Dan's enumeration scheme change, but looking at the xhci parts of the logs there seems to be both Address command timeout and halting/stalling endpoint clearing issues. There is currently an issue with clearing halted endpoints and toggle bit getting out of sync on xhci which I'm about to take on, this could be related. http://marc.info/?l=libusb-develm=134930472420570w=2 Hopefully, fixing that will solve some of the issues you are seeing as well. There's also a rfc patchset which completely changes how xhci handles command timeouts. You could also test if it has any impact on the address command timeout. http://marc.info/?l=linux-usbm=139653559120996w=2 Alright, thanks for taking a look. Benjamin, were you able to reproduce this on a different host controller? If you're interested in debugging this further you could try Mathias timeout RFC. I could prepare a branch for you to pull if that'd simplify things. This sounds interesting. If you prepare a branch, I'll certainly give it a try, thank you. There's a completely untested xhci-cmdqueue branch in my tree now that you could try: https://git.kernel.org/cgit/linux/kernel/git/johan/usb-serial.git/log/?h=xhci-cmdqueue I've simply applied Mathias series from here: http://marc.info/?l=linux-usbm=139653559120996w=2 to v3.15-rc1. I'll look for a way to test this on other hardware/different host controller. I'd definitely recommend that. It may or may not be relevant, but the vendor admits that there are issues in Windows and Mac that also prevents their software from working with USB 3.0 ports. When I asked them on the phone, they told me the reason was because the ports are the wrong size and it's not a universal system. So I know the issue is a generic one involving 3.0 handling across different operating systems/hardware, not just mine. I'll look for an opportunity to test on other hardware. Wrong size? :) Well, if the device doesn't enumerate under those other OSes either, this may be a long shot. But best of luck! Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci: non-superspeed enumeration failure (was: Re: medtronic usb productId 0x8001: usbserial support, xhci enumeration)
On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold jo...@hovold.com 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 :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 :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=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 jo...@hovold.com 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 jo...@hovold.com 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 :00:14.0: Timeout while waiting for setup address command Mar 20 00:22:50 patient kernel: [ 625.372047] xhci_hcd :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 :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.01] xhci_hcd :00:14.0: Timeout while waiting for setup address command Mar 20 00:23:16 patient kernel: [ 651.223619] xhci_hcd :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 :00:14.0: Timeout while waiting for setup address command Mar 20 00:23:27 patient kernel: [ 661.745070] xhci_hcd :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
Re: xhci: non-superspeed enumeration failure
On Tue, Apr 8, 2014 at 12:52 AM, Johan Hovold jo...@hovold.com wrote: On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote: On 04/03/2014 07:32 PM, Johan Hovold 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 :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 :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=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? It might be related to Dan's enumeration scheme change, but looking at the xhci parts of the logs there seems to be both Address command timeout and halting/stalling endpoint clearing issues. There is currently an issue with clearing halted endpoints and toggle bit getting out of sync on xhci which I'm about to take on, this could be related. http://marc.info/?l=libusb-develm=134930472420570w=2 Hopefully, fixing that will solve some of the issues you are seeing as well. There's also a rfc patchset which completely changes how xhci handles command timeouts. You could also test if it has any impact on the address command timeout. http://marc.info/?l=linux-usbm=139653559120996w=2 Alright, thanks for taking a look. Benjamin, were you able to reproduce this on a different host controller? If you're interested in debugging this further you could try Mathias timeout RFC. I could prepare a branch for you to pull if that'd simplify things. Thanks, Johan Howdy Johan, This sounds interesting. If you prepare a branch, I'll certainly give it a try, thank you. I'll look for a way to test this on other hardware/different host controller. It may or may not be relevant, but the vendor admits that there are issues in Windows and Mac that also prevents their software from working with USB 3.0 ports. When I asked them on the phone, they told me the reason was because the ports are the wrong size and it's not a universal system. So I know the issue is a generic one involving 3.0 handling across different operating systems/hardware, not just mine. I'll look for an opportunity to test on other hardware. Thanks, -bewest -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci: non-superspeed enumeration failure
On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote: On 04/03/2014 07:32 PM, Johan Hovold 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 :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 :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=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? It might be related to Dan's enumeration scheme change, but looking at the xhci parts of the logs there seems to be both Address command timeout and halting/stalling endpoint clearing issues. There is currently an issue with clearing halted endpoints and toggle bit getting out of sync on xhci which I'm about to take on, this could be related. http://marc.info/?l=libusb-develm=134930472420570w=2 Hopefully, fixing that will solve some of the issues you are seeing as well. There's also a rfc patchset which completely changes how xhci handles command timeouts. You could also test if it has any impact on the address command timeout. http://marc.info/?l=linux-usbm=139653559120996w=2 Alright, thanks for taking a look. Benjamin, were you able to reproduce this on a different host controller? If you're interested in debugging this further you could try Mathias timeout RFC. I could prepare a branch for you to pull if that'd simplify things. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci: non-superspeed enumeration failure
On 04/03/2014 07:32 PM, Johan Hovold 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 :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 :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=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? It might be related to Dan's enumeration scheme change, but looking at the xhci parts of the logs there seems to be both Address command timeout and halting/stalling endpoint clearing issues. There is currently an issue with clearing halted endpoints and toggle bit getting out of sync on xhci which I'm about to take on, this could be related. http://marc.info/?l=libusb-develm=134930472420570w=2 Hopefully, fixing that will solve some of the issues you are seeing as well. There's also a rfc patchset which completely changes how xhci handles command timeouts. You could also test if it has any impact on the address command timeout. http://marc.info/?l=linux-usbm=139653559120996w=2 -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
xhci: non-superspeed enumeration failure (was: Re: medtronic usb productId 0x8001: usbserial support, xhci enumeration)
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 :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 :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=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 jo...@hovold.com 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 jo...@hovold.com 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 :00:14.0: Timeout while waiting for setup address command Mar 20 00:22:50 patient kernel: [ 625.372047] xhci_hcd :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 :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.01] xhci_hcd :00:14.0: Timeout while waiting for setup address command Mar 20 00:23:16 patient kernel: [ 651.223619] xhci_hcd :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 :00:14.0: Timeout while waiting for setup address command Mar 20 00:23:27 patient kernel: [ 661.745070] xhci_hcd :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
