On Sun, Apr 13, 2014 at 05:04:50PM -0700, Benjamin West wrote:
> On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
