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

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

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: roxmail@list.ru
        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.

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

[bugzilla-daemon]

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

--- Comment #1 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #2 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #3 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #4 from Roman Elshin (roxmail@list.ru) ---
>  You don't unplug any USB devices while the test is running, do you?
I was`t touch anything (only move mouse)

> Can you describe the effect of the patch and explain why returning early
> should be the right thing to do?
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.

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

[bugzilla-daemon]

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

--- Comment #5 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #6 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #7 from Alan Stern (stern@rowland.harvard.edu) ---
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/20260307-usbhid-eproto-v2-1-e5a8abce4652@gmail.com/

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.

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

[bugzilla-daemon]

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

--- Comment #8 from Roman Elshin (roxmail@list.ru) ---
> Your computer must be a rather old one for the load level to affect it this
> way

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.

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

[bugzilla-daemon]

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

--- Comment #9 from Roman Elshin (roxmail@list.ru) ---
https://lore.kernel.org/linux-usb/20260307-usbhid-eproto-v2-1-e5a8abce4652@gmail.com/

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.

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

[bugzilla-daemon]

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

Liam Mitchell (mitchell.liam@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mitchell.liam@gmail.com

--- Comment #10 from Liam Mitchell (mitchell.liam@gmail.com) ---
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.

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

[bugzilla-daemon]

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

--- Comment #11 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #12 from Roman Elshin (roxmail@list.ru) ---
I was`t try usbmon with other oses, but end user symptoms looks similar.

>Yes, the reaction can be tuned to improve your experience, but that won't fix
>the underlying errors

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.

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

[bugzilla-daemon]

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

--- Comment #13 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #14 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #15 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #16 from Roman Elshin (roxmail@list.ru) ---
> 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?

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.

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

[bugzilla-daemon]

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

--- Comment #17 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #18 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #19 from Roman Elshin (roxmail@list.ru) ---
> Try modifying the 500ms to 200 or other and see if there is a noticeable
> difference.

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.

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

[bugzilla-daemon]

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

--- Comment #20 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #21 from Roman Elshin (roxmail@list.ru) ---
(In reply to Alan Stern from comment #20)
> 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.

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.

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

[bugzilla-daemon]

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

--- Comment #22 from Roman Elshin (roxmail@list.ru) ---
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.

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

[bugzilla-daemon]

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

--- Comment #23 from Liam Mitchell (mitchell.liam@gmail.com) ---
Here is V3 of the patch if you want to test:
https://lore.kernel.org/linux-usb/20260309-usbhid-eproto-v3-1-23bd841dfc91@gmail.com/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.

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

[bugzilla-daemon]

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

--- Comment #24 from Roman Elshin (roxmail@list.ru) ---
> yes, but question was about is it right? (as it broke my mouse) 

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.

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

[bugzilla-daemon]

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

--- Comment #25 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #26 from Roman Elshin (roxmail@list.ru) ---
(In reply to Liam Mitchell from comment #23)
> Here is V3 of the patch if you want to test:
> https://lore.kernel.org/linux-usb/20260309-usbhid-eproto-v3-1-
> 23bd841dfc91@gmail.com/T/#u

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.

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

[bugzilla-daemon]

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

--- Comment #27 from Roman Elshin (roxmail@list.ru) ---
> Thanks it seems to work!

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.

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

[bugzilla-daemon]

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

Michał Pecio (michal.pecio@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michal.pecio@gmail.com

--- Comment #28 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to Roman Elshin from comment #17)
> reverting 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 greatly improve usability
> -
> it fixes mouse resets, keyboard resets still here, but it makes it mach rare.
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)
> just made a quick test with several pci-e usb cards what i have
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.

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

[bugzilla-daemon]

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

--- Comment #29 from Roman Elshin (roxmail@list.ru) ---
> 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.

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.

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

[bugzilla-daemon]

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

--- Comment #30 from Roman Elshin (roxmail@list.ru) ---
> All of these are USB 3.0 and use xhci_hcd driver instead of ehci_hcd, 

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.

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

[bugzilla-daemon]

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

--- Comment #31 from Liam Mitchell (mitchell.liam@gmail.com) ---
(In reply to Roman Elshin from comment #26)
> (In reply to Liam Mitchell from comment #23)
> > Here is V3 of the patch if you want to test:
> > https://lore.kernel.org/linux-usb/20260309-usbhid-eproto-v3-1-
> > 23bd841dfc91@gmail.com/T/#u
> 
> 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.

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)
> (In reply to Roman Elshin from comment #17)
> > reverting 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 greatly improve
> usability
> > -
> > it fixes mouse resets, keyboard resets still here, but it makes it mach
> rare.
> Does this commit change anything besides returning EPROTO vs EPIPE?
> 
> What difference does it make for usbhid? Maybe it tries usb_clear_halt()?

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.

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

[bugzilla-daemon]

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

--- Comment #32 from Roman Elshin (roxmail@list.ru) ---
> My current thinking is that these errors are expected and fine but they could
> also be seen as scary and a regression.

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.

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

[bugzilla-daemon]

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

--- Comment #33 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #34 from Liam Mitchell (mitchell.liam@gmail.com) ---
(In reply to Alan Stern from comment #33)
> 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.

That doesn't match what I'm reading.

In Documentation/driver-api/usb/error-codes.rst:
> -EPIPE Endpoint stalled. For non-control endpoints, reset this status with
> usb_clear_halt().

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.

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

[bugzilla-daemon]

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

--- Comment #35 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #38 from Michał Pecio (michal.pecio@gmail.com) ---
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.

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

[bugzilla-daemon]

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

--- Comment #39 from Roman Elshin (roxmail@list.ru) ---
> I wonder if this change would help for any of the xHCI problems mentioned
> here? And what effect it has on the EHCI problems?

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.

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

[bugzilla-daemon]

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

--- Comment #40 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

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

--- Comment #41 from Roman Elshin (roxmail@list.ru) ---
> I wonder if this change would help for any of the xHCI problems mentioned
> here? And what effect it has on the EHCI problems?

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.