[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 #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.