[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 #37 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to Liam Mitchell from comment #34)
> In Documentation/driver-api/usb/error-codes.rst:

This documentation is quite old, not necessarily matches evolving landscape,
and nobody is updating it. It's not even entirely clear how to handle the mess.

Discussion on linux-usb from 2024, nothing has changed since then.
https://lore.kernel.org/linux-usb/20241121001138.23a45f6c@foxbook/T/

You may need to read some USB 2.0 spec chapters to understand those things.
8.6: the toggle protocol and retries (usually done by HW)
11.14: the horrors of low/full speed devices behind high speed (also 3.x) hubs
5.3.2: how host HW and SW were envisioned to work together
5.7.5: interrupt endpoint halts due to STALL or "transmission error"

Simple errors (corrupted packet) on bulk/int cause three retries in HW, and
then the HW halts and SW should intervene. USB 2.0 transaction translators
appear to introduce a new problem - the HC failing to fetch interrupt IN data
in time. AFAIU such packet is lost, but the device considers it delivered and
won't resend.

(Not sure how it could happen at all? Maybe DMA too slow? Perhaps Roman's
problem isn't really CPU load but RAM traffic? Not much difference, though.)

If I'm not mistaken, there is no sensible recovery from *this*. The idea was
that SW intervention would use class-specific control requests to learn true
state of the device and put things back in order. And reset toggle on both
ends, which is usb_clear_halt() in Linux.

I don't know how/if the HID spec recommends to deal with errors. Ideally, there
would be a way to query the state of all keys, but maybe there isn't.


Retries are an option too (though AFAIU they can't help with a packet lost in
TT) and xHCI is very helpful and makes them easy, but only if we don't give
back the URB. Maybe we could have a flag to never give back on EPROTO and just
keep hammering until the URB is unlinked (due to disconnection or otherwise).

The alternative is to fully reset the endpoint and clear its toggle state, at
which point the device toggle should be cleared too or there is risk of
silently losing one more packet. That's what xhci-hcd does on every EPIPE *and*
EPROTO.

In theory we could do a "transfer state preserving" reset as if before a retry,
and instead of restarting the endpoint skip the failed URB and proceed to the
next one submitted by the driver. This would match EHCI behavior AFAIU, but
it's gray area - not obviously forbidden, not discussed as an option. Chances
are some xHCI HW would get it wrong. Some HW can't even get basic retries
right. I thought about it but never really tried it.


So existing usbhid behavior seems to risk losing one more packet after EPROTO
on xHCI. You could probably see it - when a key is stuck, it could be necessary
to not only press but also release another key to fix it. Though I admit that I
tried and failed to reproduce this case. It seems I'm still missing some
detail.

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

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