[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

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.