On Thu, 9 Apr 2015, Johan Hovold wrote: > On Wed, Apr 08, 2015 at 05:29:16PM +0000, Mark Enstone wrote: > > Everyone, thank you for your attention and suggestions. > > > > Johan, perfect, thank you, that did indeed help and has fixed the > > issue I was seeing. > > > > The change replaced dev_err() with dev_dbg() -- thus not logging (by > > default) what was a very noisy flood of messages. Does that simply > > change timing enough such that the USB HCD has time to process the > > disconnect? Or is there something else going on that I'm missing? > > I'm afraid it's only working around the real issue, though. > > 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? > 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 still find it odd that the problem occurs only when the _last_ device is unplugged from the hub. Alan Stern -- 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
