linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1ebf9d19-7293-4902-857b-164fd4d21f25@rowland.harvard.edu>
Date: Sun, 1 Feb 2026 15:40:34 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Liam Mitchell <mitchell.liam@...il.com>
Cc: Jiri Kosina <jikos@...nel.org>, Benjamin Tissoires <bentiss@...nel.org>,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: usbhid: Intermittent EPROTO errors trigger USB reset and
 interrupt user input

On Sun, Feb 01, 2026 at 06:57:06PM +0100, Liam Mitchell wrote:
> 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

There should not be this many EPROTO errors.  The fact that you get them 
indicates some sort of hardware problem.  Have you tried swapping the 
cables, hub, keyboard, and trackpad for different ones to see if that 
makes any difference?

> 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?

It's possible to do all these things, as far as I know.  However, it 
would be better to eliminate the errors completely.

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

Not that I'm aware of, other than just by retrying.

Alan Stern