linux-kernel - usbhid: Intermittent EPROTO errors trigger USB reset and interrupt user input

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ1CL6Q+4GNy=kgisLzs0UBXFT3b02PG8t-0rPuW-Wf6NhQ6g@mail.gmail.com>
Date: Sun, 1 Feb 2026 18:57:06 +0100
From: Liam Mitchell <mitchell.liam@...il.com>
To: Jiri Kosina <jikos@...nel.org>, Benjamin Tissoires <bentiss@...nel.org>
Cc: linux-usb@...r.kernel.org, linux-input@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: usbhid: Intermittent EPROTO errors trigger USB reset and interrupt
 user input

Hi,

I'm trying to understand and fix intermittent keyboard/trackpad issues
on my 2013 MacBook Pro running Linux v6.18.4:
- missed/repeated/sticky keys while typing (this thread)
- trackpad stops working (see "bcm5974 trackpad broken after USB
reset" in linux-input)

The keyboard (usbhid) and trackpad (bcm5974) are interfaces of a
single full-speed device behind a high-speed hub:

/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
        ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
        |__ Port 008: Dev 003, If 0, Class=Hub, Driver=hub/2p, 480M
            ID 0424:2512 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
            |__ Port 002: Dev 005, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
                ID 05ac:0259 Apple, Inc. Internal Keyboard/Trackpad
            |__ Port 002: Dev 005, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
                ID 05ac:0259 Apple, Inc. Internal Keyboard/Trackpad
            |__ Port 002: Dev 005, If 2, Class=Human Interface Device,
Driver=bcm5974, 12M
                ID 05ac:0259 Apple, Inc. Internal Keyboard/Trackpad

Logs preceding one of these events:

[19607.563871] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19611.523681] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19614.550685] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19614.563878] usbhid: usbhid 3-1.8.2:1.0: retrying intr urb
[19615.050802] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19615.067673] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19616.822636] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19616.835934] usbhid: usbhid 3-1.8.2:1.0: retrying intr urb
[19618.126656] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb status: -71
[19618.126711] usbhid: usbhid 3-1.8.2:1.0: resetting device
[19618.126728] usbcore: bcm5974 3-1.8.2:1.2: forced unbind
[19618.129942] bcm5974: bcm5974 3-1.8.2:1.2: trackpad urb shutting down: -2
[19618.155292] usbcore: usb 3-1.8-port2: not reset yet, waiting 10ms
[19618.217146] usb 3-1.8.2: reset full-speed USB device number 5 using ehci-pci

Both interfaces receive frequent EPROTO errors. I collected statistics
on the error interval over a 30 min idle period:
Interface, Count, Mean (s), Std Dev (s), Median (s), Min (s), Max (s)
Trackpad (bcm5974), 631, 3.21, 4.75, 1.74, 0.01, 35.62
Keyboard (usbhid), 71, 26.82, 24.90, 19.34, 0.92, 107.74

>From debugging I understand these to be missed micro-frame (MMF)
timing errors in the host controller. They require URB reset but not a
reset of the whole device.

The bcm5974 driver simply re-submits the interrupt URB. This is the
best behavior for these errors on my machine.

The more "correct" usbhid driver will delay URB re-submission and even
reset the device if a second error is received within a 1.5 second
timeout. It's these periods between EPROTO error and re-submission of
URB where keyboard events are missed (missed keyup == key stays down
and repeats). The default error retry delay of 13ms is relatively
small but a full device reset takes about 200ms. With the frequency of
errors I'm seeing, every ms counts.

Can we improve the usbhid error handling for these cases?
1. Reduce first retry delay from 13ms to 1ms?
2. Reduce the stop retry (reset) timeout from 1.5s to 500ms? 100ms?
3. Require 3 or more errors in the timeout before resetting?
4. Ignore EPROTO errors for known hardware/quirks?

Are there ways to differentiate these safe-to-retry MMF/EPROTO errors
from others that may really need a full device reset?

Appreciate your thoughts.
Thanks,
Liam