[ Adding Mathias Nyman as CC. ] 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: > >> >> issues. It's included below > >> >> https://gist.github.com/bewest/6488955#file-lsusb > >> > >> > I'm responding to this mail with a patch for you to test. The patch is > >> > also available here: > >> > > >> > https://git.kernel.org/cgit/linux/kernel/git/johan/usb-serial.git/log/?h=carelink > >> > > >> > as a commit on top of usb-next. It's quite likely that the problem > >> > you've been having has already been fixed (in v3.14-rc) so I suggest > >> > just testing the carelink branch above. Remember to enable the > >> > usb-serial-simple driver. > > 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. > Something else interesting happened as well. > At some point, I got the following messages in the logs. After > receiving these messages, I tried several different usb devices, but > they all fail to enumerate after this. > > Sarah's branch seemed to enumerate consistently, but hard to quantify; > I'll bang on it a bit more, and try to keep track of error vs success > rates. > > -bewest > > P. S. I wasn't doing my usual log capture routine, but I believe I saw > these messages, after which no log messages appear, even when > inserting/removing other usb devices. > https://gist.github.com/bewest/6488955#file-broken-usb-stack-log > > 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 08:03:16 patient whoopsie[1220]: online > Mar 20 08:04:37 whoopsie[1220]: last message repeated 2 times > Mar 20 08:05:37 whoopsie[1220]: last message repeated 3 times > Mar 20 08:05:40 patient kernel: [28385.152074] xhci_hcd 0000:00:14.0: > Timeout while waiting for a slot > Mar 20 08:05:40 patient kernel: [28385.152081] hub 3-0:1.0: couldn't > allocate port 2 usb_device > Mar 20 08:06:24 patient NetworkManager[867]: <warn> nl_recvmsgs() > error: (-33) Dump inconsistency detected, interrupted > Mar 20 08:06:37 patient whoopsie[1220]: online > Mar 20 08:07:37 whoopsie[1220]: last message repeated 2 times > Mar 20 08:08:37 whoopsie[1220]: last message repeated 3 times > Mar 20 08:09:56 patient whoopsie[1220]: online > Mar 20 08:11:08 whoopsie[1220]: last message repeated 2 times > Mar 20 08:12:08 whoopsie[1220]: last message repeated 3 times > Mar 20 08:13:16 patient whoopsie[1220]: online > Mar 20 08:13:17 patient whoopsie[1220]: online > Mar 20 08:13:21 patient bluetoothd[781]: Adapter /org/bluez/781/hci0 > has been disabled > Mar 20 08:13:21 patient bluetoothd[781]: Unregister path: /org/bluez/781/hci0 > Mar 20 08:13:21 patient bluetoothd[781]: Endpoint unregistered: > sender=:1.52 path=/MediaEndpoint/A2DPSink > Mar 20 08:13:21 patient bluetoothd[781]: Endpoint unregistered: > sender=:1.52 path=/MediaEndpoint/A2DPSource > Mar 20 08:13:21 patient bluetoothd[781]: Endpoint unregistered: > sender=:1.52 path=/MediaEndpoint/HFPAG > Mar 20 08:13:21 patient bluetoothd[781]: Endpoint unregistered: > sender=:1.52 path=/MediaEndpoint/HFPHS > Mar 20 08:13:21 patient colord: device removed: sysfs-Generic-BisonCam__NB_Pro > Mar 20 08:13:21 patient kernel: [28846.341209] xhci_hcd 0000:00:14.0: > xHCI host not responding to stop endpoint command. > Mar 20 08:13:21 patient kernel: [28846.341213] xhci_hcd 0000:00:14.0: > Assuming host is dying, halting host. > Mar 20 08:13:21 patient kernel: [28846.341232] Bluetooth: hci0 urb > ffff880405e7b900 failed to resubmit (22) > Mar 20 08:13:21 patient kernel: [28846.341237] Bluetooth: hci0 urb > ffff880405e7b540 failed to resubmit (22) > Mar 20 08:13:21 patient kernel: [28846.341240] Bluetooth: hci0 urb > ffff880405e7b840 failed to resubmit (22) > Mar 20 08:13:21 patient kernel: [28846.341245] xhci_hcd 0000:00:14.0: > HC died; cleaning up Not sure what to make of this, but again, hopefully someone of xhci-people might be able to help. Have you tried reproducing this on a different machine and xhci-controller? Thanks, 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
