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