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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
