On Tue, 11 Aug 2015, Oliver Neukum wrote: > 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. ENODEV is the error code for "the device has been removed". > 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. In general the errors should be EPROTO, EILSEQ, or ETIME. In Yegor's case the errors undoubtedly were genuine, since he said they starting occurring when he unplugged the USB device. > > 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. It would be nice to put this logic in a library where many drivers could share it, although I can't immediately think of any good way to do that. The logic is complicated enough that we don't want lots of drivers all rolling their own implementations. > Detection of a hot unplug is not immediate. It may take a few hundred > ms. Right. External hubs are polled for port-status changes every 256 ms. (In theory -- in practice it often ends up being 128 ms because HCDs like to use powers of 2, and the descriptor that holds the period is an unsigned 8-bit value, so it only goes up to 255.) Alan Stern -- 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
