On Thu, Apr 09, 2015 at 02:25:08PM -0400, Alan Stern wrote: > On Thu, 9 Apr 2015, Johan Hovold wrote: > > In my setup, adding a really short udelay (e.g. 100 us) rather than the > > printk is also enough to trigger the lock up when using just two bulk-in > > urbs. > > > > I thought it was the hub-driver work queue that was starved, but in my > > current setup I don't even get a completion callback for the external > > hub port-status change. > > Is that the hub driver's interrupt URB? Or do you mean a control URB > requesting the port status? The hub driver's interrupt URB. > > Same issue with two HS hubs of the same type. > > > > Switching to a different hub appears to make the problem go away. But so > > does using the same hub with a different HC (ehci-omap). So can't rule > > out musb (and dwc2 on RPi?). > > > > I'll try to find some more time to look into this later. > > > > Alan, what are your thoughts on this? > > > > My setup is > > > > Beaglebone Black musb -> HS hub -> FS device > > It's awfully hard to pin down the cause of a problem when changing > either of two components makes the problem go away. > > In this case, I'd start with a bus analyzer. Does the URB in question > get transmitted? Does the hub send back a reply? This will at least > help pin down whether the problem starts in the host controller or in > the hub. I don't have one available at the moment, but I'll try that later. > I still find it odd that the problem occurs only when the _last_ device > is unplugged from the hub. I just tested with a second device connected and that does not seem to change the behaviour in my setup. 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
