On Tue, 2015-08-11 at 13:48 +0200, Bjørn Mork wrote:
> I wonder if this is related to different platforms using different
> errors for this event? As you can see, I get ESHUTDOWN where you got
> EPROTO. The driver resubmits the URB in the EPROTO case. And that's
> probably why you end up with a dead system. Although I would have
> thought that the submit should immediately return an error, the fact
> that you get multiple error messages for the same device proves that
> the
> resubmit results in the callback being executed. I guess it ends up
> in
> a tight resubmit loop.
That is possible.
>
> I hope some of the USB experts can tell us what the correct behaviour
> is
> here. Should the driver treat EPROTO like ESHUTDOWN? Or should the
> host controller use some ESHUTDOWN instead?
No. ESHUTDOWN is reserved for the removal of the HC.
What errors a driver gets talking to a removed device is
not defined and depends in part on the hardware involved.
Some of these errors may be genuine.
>
> If so, what about other errors? If the assumptions above are correct,
> then it seems that any unhandled persistent error can send the driver
> into a hard loop. That doesn't seem right...
The driver that does handle it in an exemplary manner is HID.
You ought to limit the number of immediate retries to a very low
number, then use a timer with exponential backoff and then proceed
to reset, if applicable.
Detection of a hot unplug is not immediate. It may take a few hundred
ms.
HTH
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
