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. 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 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
