New: mouse/keyboard (connected via hub) usb reset under system load with weak cpu

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

Bug ID: 221184
Summary: mouse/keyboard (connected via hub) usb reset under
system load with weak cpu
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Created attachment 309564
--> https://bugzilla.kernel.org/attachment.cgi?id=309564&action=edit
dmesg

There are occasionally mouse/keyboard (connected via usb hub) resets, seems it is coursed by high system`s cpu load. I found a "quick" reproducer - it is firefox and moving photo test
(https://testufo.com/photo#photo=quebec.jpg&pps=960&pursuit=0&height=0)

Partly it is regression - mouse resets intoduced by commit:
[64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832] USB: EHCI: Do not return -EPIPE when hub is disconnected.

with attached patch there are no usb resets and mouse/keyboards are quite usable it this conditions (while firefox test), only backside effect what i see
- it`s some errors in dmesg at devices removing.

You may reply to this email to add a comment.

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

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

--- Comment #1 from Roman Elshin ([email protected]) --- Created attachment 309565
--> https://bugzilla.kernel.org/attachment.cgi?id=309565&action=edit
lsusb -tv

You may reply to this email to add a comment.

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

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

--- Comment #2 from Roman Elshin ([email protected]) --- Created attachment 309566
--> https://bugzilla.kernel.org/attachment.cgi?id=309566&action=edit
patch

You may reply to this email to add a comment.

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

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

--- Comment #3 from Alan Stern ([email protected]) --- Can you carry out your test, without the patch in comment #2, while collecting a usbmon trace of the affected bus? The trace ought to show us what's going on, in some detail.

You don't unplug any USB devices while the test is running, do you?

Can you describe the effect of the patch and explain why returning early should be the right thing to do?

You may reply to this email to add a comment.

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

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

--- Comment #4 from Roman Elshin ([email protected]) ---

I was`t touch anything (only move mouse)

I don`t know what i am doing here - it completely a shot in the dark while looking at the broken commit.
With this patch mouse and keyboard work as expected, only messages like this :

[   67.986466] hid-generic 0003:046D:C53F.0004: can't resubmit intr,
0000:00:1d.7-5.4/input1, status -19
[   67.986604] hid-generic 0003:046D:C53F.0003: can't resubmit intr,
0000:00:1d.7-5.4/input0, status -19
[   67.986745] hid-generic 0003:0603:00F5.0002: can't resubmit intr,

0000:00:1d.7-5.3/input1, status -19

at removing a hub (or single error if one device are removed) in dmesg.

You may reply to this email to add a comment.

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

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

--- Comment #5 from Roman Elshin ([email protected]) --- Created attachment 309569
--> https://bugzilla.kernel.org/attachment.cgi?id=309569&action=edit
usbmon out

You may reply to this email to add a comment.

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

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

--- Comment #6 from Roman Elshin ([email protected]) --- Created attachment 309570
--> https://bugzilla.kernel.org/attachment.cgi?id=309570&action=edit
lsusb -tv while usbmon

You may reply to this email to add a comment.

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

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

--- Comment #7 from Alan Stern ([email protected]) --- The usbmon trace shows that your system is getting a lot of communication errors (multiple errors per second sometimes), probably caused by the system load as you said. You can see them yourself in the trace; look for lines containing a "-71" code, and note that the second column of each line is a timestamp in microseconds. (Your computer must be a rather old one for the load level to affect it this way -- also, the lsusb output shows that the computer has no USB-3 ports, only USB-2.)

With many of these errors the HID driver simply retries the transfer, and that works, but sometimes it decides there have been too many errors too rapidly and it resets the device in an attempt to recover.

As it happens, Liam Mitchell has just submitted a patch to increase the HID driver's tolerance for these communication errors:

https://lore.kernel.org/linux-usb/[email protected]/

I'm not sure how much it will help in your case, because the errors you get occur so frequently, but it might help some. Perhaps the patch can be improved even more.

As for your patch in comment #2... It is totally the wrong thing to do. When an error causes the endpoint to halt, the driver needs to know. If qtd_copy_status() returns early for short transfers (which is what your patch makes it do), the driver won't realize that the endpoint has halted. To put it another way, these sorts of errors should not be ignored by ehci-hcd, although the higher-level HID driver may decide to ignore them.

You may reply to this email to add a comment.

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

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

--- Comment #8 from Roman Elshin ([email protected]) ---

yes it is Pentium-D 3.2gHz :), but it strange to see such HID behaviur while, for example, OS booted from usb disk connected to this hub works just fine (except performance and this of course), thanks for detailed reply, will test.

You may reply to this email to add a comment.

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

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

--- Comment #9 from Roman Elshin ([email protected]) ---
https://lore.kernel.org/linux-usb/[email protected]/

seems a have some positive impact, but it definitely does`t solve issue fully in my case.

You may reply to this email to add a comment.

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

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

Liam Mitchell ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #10 from Liam Mitchell ([email protected]) --- Thanks for trying it out!

I prompted a script to analyze your logs, producing the following:

USB ACTUAL OBSERVED DATA (Total log duration: 117.8s)
Times are in milliseconds, formatted as min/max/average
Interface | Errors | Resets | Submit-Error | Error-Resubmit | Reset-Submit | Total Wait
-----------+--------+--------+--------------+----------------+--------------+-----------
Ii:4:003:1 | 36 | 12 | 16/5678/814 | 16/458/67 | 93/221/144 |
2430ms
Ii:4:003:2 | 33 | 12 | 18/4098/859 | 16/457/70 | 93/221/144 |
2321ms
Ii:4:004:1 | 32 | 8 | 38/2973/855 | 17/291/70 | 93/99/96 |
2245ms
Ii:4:004:2 | 30 | 8 | 2/2139/354 | 16/277/38 | 93/99/96 |
1142ms

Legend: 4:003 = Novatek Microelectronics Corp., 4:004 = Logitech, Inc.

It shows 20 resets and about 2s of device downtime in the 2 minute period.

I then prompted for a script to use the actual submit-error times to estimate the resets and total wait time for 3 models:
- baseline: current error handling, 13/26/52/104/104ms backoff retry, reset on error at 1-1.5s
- 500ms tolerance, the above with my patch ignoring one proto error every 500ms, resubmitting immediately
- 200ms tolerance, the above with shorter window

USBHID ERROR HANDLING MODELS (Predicted Resets / Total wait time)
Interface | Baseline | 500ms tolerance | 200ms tolerance
-----------+------------+-----------------+----------------

Ii:4:003:1 | 5 / 2280ms | 0 / 507ms       | 0 / 117ms
Ii:4:003:2 | 5 / 1994ms | 0 / 507ms       | 0 / 117ms
Ii:4:004:1 | 8 / 2007ms | 1 / 512ms       | 0 / 195ms
Ii:4:004:2 | 8 / 1903ms | 1 / 382ms       | 0 / 143ms

The baseline numbers don't exactly match the actual but it looks close enough to me for comparison.

It predicts what you reported, has positive impact but doesn't fully solve the issue.

Try modifying the 500ms to 200 or other and see if there is a noticeable difference.

The window shouldn't go lower than 100 or so to prevent the system being locked.

Somewhere there is a number that balances making unreliable devices useful with protecting the system from locking and resetting devices that need it.

You may reply to this email to add a comment.

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

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

--- Comment #11 from Alan Stern ([email protected]) --- Re comment #8: Are you sure that other operating system versions really are working fine? Have you tried collecting a usbmon trace under another OS version while running your load test, and looking through the trace for -71 errors?

Those errors are the underlying cause of the problems you face. The mouse and keyboard resets are merely the kernel's reaction to the errors. Yes, the reaction can be tuned to improve your experience, but that won't fix the underlying errors.

You may reply to this email to add a comment.

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

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

--- Comment #12 from Roman Elshin ([email protected]) ---
I was`t try usbmon with other oses, but end user symptoms looks similar.

patch looks incorrect for me: between "bad" events may exist many good, and

time_after(jiffies, usbhid->last_proto_error + msecs_to_jiffies(500))

will be false in this case?

You may reply to this email to add a comment.

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

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

--- Comment #13 from Alan Stern ([email protected]) --- In the patch's email thread, Liam and I are discussing other possible approaches. One of them might help a lot with your problem.

You may reply to this email to add a comment.

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

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

--- Comment #14 from Roman Elshin ([email protected]) --- Created attachment 309575
--> https://bugzilla.kernel.org/attachment.cgi?id=309575&action=edit
usbmon log from debian sid

debian sid kernel: 6.18.15+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.15-1 (2026-02-27) x86_64 GNU/Linux

System booted from sata ssd (previous logs was from 32bit debian-11 and hdd)

You may reply to this email to add a comment.

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

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

--- Comment #15 from Alan Stern ([email protected]) --- The new usbmon trace clearly shows the same errors as the earlier one. It even shows at least one reset (I didn't look through the whole file). So although the newer OS may behave somewhat worse than the earlier one, it did not introduce a new bug.

You may reply to this email to add a comment.

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

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

--- Comment #16 from Roman Elshin ([email protected]) ---

Error reason are -EPROTO from ehci, and at least for mouse was introduced by 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832, reverting this fixing at least mouse resets (need retest with current kernel), looking at code i am wonder if it ever correct, code part (ehci-q.c):
---------------------------------------------------------------------------

                /*
                 * When MMF is active and PID Code is IN, queue is halted.
                 * EHCI Specification, Table 4-13.
                 */
                } else if ((token & QTD_STS_MMF) &&
                                        (QTD_PID(token) == PID_CODE_IN)) {
                        status = -EPROTO;
                /* CERR nonzero + halt --> stall */
                } else if (QTD_CERR(token)) {
                        status = -EPIPE;

                /* In theory, more than one of the following bits can be set
                 * since they are sticky and the transaction is retried.
                 * Which to test first is rather arbitrary.
                 */
                } else if (token & QTD_STS_MMF) {
                        /* fs/ls interrupt xfer missed the complete-split */
                        status = -EPROTO;

-----------------------------------------------------------------------------
why additional check:

((token & QTD_STS_MMF) && (QTD_PID(token) == PID_CODE_IN))

needed here (it was introduced by 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832), there are (token & QTD_STS_MMF) already check with same return status later ?

You may reply to this email to add a comment.

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

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

--- Comment #17 from Roman Elshin ([email protected]) --- Created attachment 309579
--> https://bugzilla.kernel.org/attachment.cgi?id=309579&action=edit
usbmon out with reverted 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832

reverting 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 greatly improve usability - it fixes mouse resets, keyboard resets still here, but it makes it mach rare.

You may reply to this email to add a comment.

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

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

--- Comment #18 from Roman Elshin ([email protected]) --- Created attachment 309580
--> https://bugzilla.kernel.org/attachment.cgi?id=309580&action=edit
reverted 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 patch

You may reply to this email to add a comment.

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

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

--- Comment #19 from Roman Elshin ([email protected]) ---

I was try some different times, and now i suppose that i was wrong about positive impact - sorry about (in some moment i thinking that 150ms almost good, but looks like it little random...)

You may reply to this email to add a comment.

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

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

--- Comment #20 from Alan Stern ([email protected]) --- Re comment #16: Consider what will happen when (token & QTD_STS_MMF) and QTD_PID(token) == PID_CODE_IN and QTD_CERR(token) are all true. In this case we want status to be set to -EPROTO, not -EPIPE.

You may reply to this email to add a comment.

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

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

--- Comment #21 from Roman Elshin ([email protected]) --- (In reply to Alan Stern from comment #20)

yes, but question was about is it right? (as it broke my mouse)

You may reply to this email to add a comment.

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

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

--- Comment #22 from Roman Elshin ([email protected]) --- just made a quick test with several pci-e usb cards what i have:

1. Fresco logic FL1100 - always immediately after start test mouse stops work, hot plug stop work (silently, without usb resets) - unusable here.

2. Renesas uPD720201 - works flawlessly here.

3. ASMedia ASM1042A - mouse/keyboard suddenly stops to work without any special load (silently, without usb resets) - completely unusable here.

4. VIA VL805 - mouse stuttering, keyboard skips pressing and sometimes repeats pressing till next press without any special load, under load completely unusable (silently, no usb resets).

You may reply to this email to add a comment.

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

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

--- Comment #23 from Liam Mitchell ([email protected]) --- Here is V3 of the patch if you want to test:
https://lore.kernel.org/linux-usb/[email protected]/T/#u

You may reply to this email to add a comment.

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

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

--- Comment #24 from Roman Elshin ([email protected]) ---

It is not possible edit reply here, sorry it should be :

yes, but question a still about is it right? (as it broke my mouse)

You may reply to this email to add a comment.

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

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

--- Comment #25 from Alan Stern ([email protected]) --- The change was correct, in the sense that it made the kernel do the right thing whereas before it would sometimes do the wrong thing.

Making the mouse more difficult to use was an unfortunate side effect. Fixing that difficulty is the subject of Liam's work. Try his new patch from comment #23; I expect it will improve your situation a lot.

You may reply to this email to add a comment.

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

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

--- Comment #26 from Roman Elshin ([email protected]) --- (In reply to Liam Mitchell from comment #23)

Thanks it seems to work!, but at hub removing:

[  859.967317] hid-generic 0003:046D:C53F.0008: can't resubmit intr,
0000:00:1d.7-5.4/input0, status -19
[  859.967329] hid-generic 0003:0603:00F5.0007: can't resubmit intr,
0000:00:1d.7-5.3/input1, status -19
[  859.967336] hid-generic 0003:046D:C53F.0009: can't resubmit intr,

0000:00:1d.7-5.4/input1, status -19

at dmesg.

You may reply to this email to add a comment.

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

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

--- Comment #27 from Roman Elshin ([email protected]) ---

It definitely work! - i retest patch after git reset --hard; git clean -dxf; git pull (and "can't resubmit intr," errors are here)

You may reply to this email to add a comment.

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

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

Michał Pecio ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #28 from Michał Pecio ([email protected]) --- (In reply to Roman Elshin from comment #17)

Does this commit change anything besides returning EPROTO vs EPIPE?

What difference does it make for usbhid? Maybe it tries usb_clear_halt()?

(In reply to Roman Elshin from comment #22)

All of these are USB 3.0 and use xhci_hcd driver instead of ehci_hcd, which is a separate can of worms (also bugs). Resubmitting without usb_clear_halt() gives 50% chance of toggle mismatch and losing the next packet on bulk EPs; AFAIK interrupt would do the same. And in some cases usb_clear_halt() may not work either.

Were you testing with devices behind a high-speed hub, or a full-speed hub, or connected directly to the card? BTW, VL805 contains a built-in HS hub.

You may reply to this email to add a comment.

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

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

--- Comment #29 from Roman Elshin ([email protected]) ---

Super-speed, i suppose (usb3) - it is 4-port, self-powered, vl817 based hub.

You may reply to this email to add a comment.

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

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

--- Comment #30 from Roman Elshin ([email protected]) ---

Ops, out of mind, this moment, i have a several pci cards (ali, nec and via VT6212l), 2-port ali usb2 card was also tested and it similar original report, but in general ali looks very buggy (have a several ali cards).

You may reply to this email to add a comment.

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

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

--- Comment #31 from Liam Mitchell ([email protected]) --- (In reply to Roman Elshin from comment #26)

The errors are because the patch allows protocol errors to be resubmitted immediately via the working correctly code path. If the error is intermittent, this is ideal because it resubmits the URB with minimal delay, reducing the chance of missed events. If the error is not intermittent (unplugging device), the resubmission fails and logs an error. Previous behavior was to always defer resubmission via hid_io_error and hid_start_in which don't log resubmission errors and because of the min 13ms delay, may not have even attempted resubmission.

My current thinking is that these errors are expected and fine but they could also be seen as scary and a regression. If you unplug monitor/network/disk, would you expect to see errors? I think the benefit to users is worth the occasional error log.

(In reply to Michał Pecio from comment #28)

I think that's the only practical difference.

EPIPE flow:
schedule_work() -> hid_reset() -> usb_clear_halt() -> hid_start_in() -> usb_submit_urb()

You may reply to this email to add a comment.

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

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

--- Comment #32 from Roman Elshin ([email protected]) ---

I am agree, and was mentioning it for case if it`s unexpected.

You may reply to this email to add a comment.

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

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

--- Comment #33 from Alan Stern ([email protected]) --- As far as I'm concerned, those status -19 error messages can be changed to debug messages, so they won't bother people. Of course, that can be done in a separate patch.

One of Michał Pecio's points is that if you want to retry following a -EPROTO error, it is necessary to reset the endpoint first by calling usb_clear_halt() -- just like with a -EPIPE error. I think usbhid may not do this; if it doesn't then it needs to be fixed.

You may reply to this email to add a comment.

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

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

--- Comment #34 from Liam Mitchell ([email protected]) --- (In reply to Alan Stern from comment #33)

That doesn't match what I'm reading.

In Documentation/driver-api/usb/error-codes.rst:

From what I understand "stalled" is a device state and requires communication with the device to clear.

EPROTO/EILSEQ are host controller errors representing communication failure. They can't be fixed, only acknowledged and retried. Calling usb_clear_halt() for these would unnecessarily delay retry.

You may reply to this email to add a comment.

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

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

--- Comment #35 from Alan Stern ([email protected]) --- 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.

You may reply to this email to add a comment.

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

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

--- Comment #36 from Liam Mitchell ([email protected]) --- (In reply to Alan Stern from comment #35)

I see this comment in drivers/usb/host/xhci-ring.c:

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.

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

--- Comment #37 from Michał Pecio ([email protected]) --- (In reply to Liam Mitchell from comment #34)

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.

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

--- Comment #38 from Michał Pecio ([email protected]) ---
I have a repro of usbhid toggle mismatch and unnecessary packet loss on xHCI.

1. press and hold a key
2. briefly disconnect D+ to break communication (D- if a full speed device)
3. xhci-hcd resets host toggle, but device toggle is unaffected
4. release the key - the host ignores device packet due to toggle mismatch

There is 50% chance that host toggle is already zero and reset does nothing. If the above doesn't work, flip toggle by pressing two keys one by one and releasing them together to generate three packets. Then repeat steps 1-4.

Moving the EPROTO case to EPIPE case seems to fix it. (I also added msleep(500) before the call to usb_clear_halt() to give myself time to reconnect D+, otheriwse usb_clear_halt() fails and the device is reset).

I wonder if this change would help for any of the xHCI problems mentioned here? And what effect it has on the EHCI problems?

You may reply to this email to add a comment.

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

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

--- Comment #39 from Roman Elshin ([email protected]) ---

Will test, but not sure how soon it will be (may be tomorrow).

You may reply to this email to add a comment.

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

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

--- Comment #40 from Alan Stern ([email protected]) --- For USB-2, mismatched toggles usually don't hurt. Mismatches occur when an ACK packet is lost, so the sender thinks its data wasn't received but the receiver thinks it was. When this happens, the sender will resend the same data using the old toggle value; the receiver will note the mismatch and ignore the duplicate data while acknowledging it. This is part of the reason why the USB stack historically has not included much error handling for EPROTO errors.

USB-3 is more complicated, and the host controller hardware keeps track of more information that USB-2 host controllers do. Re-establishing correct synchronization after an error is therefore all the more difficult. It would be worth some effort to find a solution that can work for both USB-2 and USB-3.

You may reply to this email to add a comment.

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

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

--- Comment #41 from Roman Elshin ([email protected]) ---

1. There are some improvements with FL1100 - while test mouse silently stops working sometimes, but after reconnecting it works again. Now i remember looking similar issue on much more recent system with i7-13700, but it very rare there (was`t pay mach attention on it so not sure about conditions).

2. ASM1042A seems no changes.

3. VIA VL805 without load seems better, but while test it looks similar as before.

With EHCI it looks similar reverting 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 (i.e. mouse works, keyboard resets while test).

You may reply to this email to add a comment.

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