[Bug 221184] mouse/keyboard (connected via hub) usb reset under system load with weak cpu

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221184

--- Comment #36 from Liam Mitchell (mitchell.liam@gmail.com) ---
(In reply to Alan Stern from comment #35)
> Yes, EPROTO represents a communication failure.  However, it only means that
> the host thinks there was a failure; there's no way to know what the device
> thinks.  Furthermore, xHCI controllers require an endpoint reset in order to
> recover from the failure.
> 
> As a result of these two facts, it is entirely possible that the endpoint
> state held in the host is no longer in agreement with the state held in the
> device.  If it isn't, a retry would apparently succeed but in fact the
> device would ignore the data that was sent or repeat the data that it sent
> previously, or maybe not respond at all.
> 
> The only way to make sure the two states are back in agreement is to reset
> them both.  That's what usb_clear_halt() does.

I see this comment in drivers/usb/host/xhci-ring.c:
>        * Proper error code is unknown here, it would be -EPIPE if device side
>        * of enadpoit halted (aka STALL), and -EPROTO if not (transaction
>error)
>        * We use -EPROTO, if device is stalled it should return a stall error
>on
>        * next transfer, which then will return -EPIPE, and device side stall
>is
>        * noted and cleared by class driver.

From this I understand:

1. xhci has the same understanding of error codes
EPIPE is a stall, driver should clear with usb_clear_halt()
EPROTO has no expectation of driver clearing halt

2. xhci clears non-stall halts automatically

3. stalled devices should continue to report stall even if first report was
missed

My understanding of usbhid is that it only listens to independent event
packets. There is no protocol state to keep in sync.

If that's correct, the optimal handling of EPROTO is to resubmit URB as soon as
possible (with backoff on repeated errors) to reduce the chance of missed
events.

If the device is actually stalled, an EPIPE should come eventually and be fixed
with usb_clear_halt().

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.