On 06/09/2010 05:38 AM, Alexander Kurpiers wrote:
On 09.06.2010 13:44, Gadiyar, Anand wrote:
Alexander Kurpiers wrote:
Gadiyar, Anand wrote:
Alan Stern wrote:
On Mon, 7 Jun 2010, Gadiyar, Anand wrote:
Hi all,
On the OMAP3, we have a new hardware bug that causes the
EHCI controller to lock up under heavy stress. The only
known way to recover is to soft-reset the controller.
I'm trying to implement some kind of recovery mechanism
for the ehci-omap driver. Is there a way to inform the
USB core that the root-hub and down-stream devices have
been reset and need to be re-enumerated?
There's usb_hc_died(). It tells the core that the controller has
stopped working. The core then removes all devices below the root hub
and marks the root hub as non-operational (the state is set to
USB_STATE_NOTATTACHED). But there is no re-enumeration; from that
point on the root hub is unusable.
This may not be exactly what you want. Perhaps a better match would be
usb_reset_device(), but that routine specifically excludes root hubs.
You might be able to adjust it in some way, though.
Another alternative is simply to unregister the hcd and then
re-register it.
(Sorry, hit send before completing the mail)
Thanks! As a quick test, I built the driver as a module. And
in the remove path, we soft-reset the controller anyway.
as I was the one who originally reported this problem, I can tell you
that soft-reset of EHCI is not enough. I had to reset UHH to recover -
sometimes losing EHCI for good, but I guess that was something else in
the end.
Yes, we need to soft-reset the whole block through the UHH_SYSCONFIG,
not just EHCI.
I am still not able to make this mechanism work reliably. I've tried
a "save-functional-registers, soft-reset, restore-registers" approach
and it used to work a little better.
Another problem is detecting the lockup itself...
This was rather easy: the IAA watchdog triggered and looking at the QTD
in question you could see that it was stuck on the setup packet as far
as I remember (I still must have some traces in the office). I never saw
the problem on anything else by EP0 - but in fact that is what the bug
description says anyway.
So what would need to be done is: detect, reset and then re-trigger
device detection and enumeration.
I can give you a test case where you can quite reliably trigger the
problem within 10min to 1h.
--
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
Any progress on this? I've recently discovered that I'm running into
this issue when using a USB radio (ar9170) on the OMAP3x EHCI while
using the OMAP ISP to capture from a camera. I'm running into the issue
within minutes to an hour and am looking for any workaround including
how I might reduce the likelyhood of the issue.
Thanks,
Tim
--
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
