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

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

[Liam Mitchell]

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

Re: usbhid: Intermittent EPROTO errors trigger USB reset and interrupt user input

[Alan Stern]

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

Re: usbhid: Intermittent EPROTO errors trigger USB reset and interrupt user input

[Liam Mitchell]

On Sun, 1 Feb 2026 at 21:40, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> 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?

Thanks for the reply,

These are the laptops internal keyboard/trackpad/hub. I would have to
remove the glued-in battery to even unplug the internal cables. If
it's a hardware issue, I'm assuming it was like this out of the
factory.

I haven't had problems with external devices, they go through a
different USB controller.

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

Liam

Re: usbhid: Intermittent EPROTO errors trigger USB reset and interrupt user input

[Oliver Neukum]

On 01.02.26 21:40, Alan Stern wrote:
> 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)

Alan,

this raises a question. What happens to KEY_UP events generated in
between the last EPROTO and the reset? It seems to me like we need
to assume that a reset implies that all keys have been released.

	Regards
		Oliver

Re: usbhid: Intermittent EPROTO errors trigger USB reset and interrupt user input

[Alan Stern]

On Mon, Feb 02, 2026 at 04:48:49PM +0100, Oliver Neukum wrote:
> 
> 
> On 01.02.26 21:40, Alan Stern wrote:
> > 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)
> 
> Alan,
> 
> this raises a question. What happens to KEY_UP events generated in
> between the last EPROTO and the reset? It seems to me like we need
> to assume that a reset implies that all keys have been released.

That question is specialized to keyboards.  You could ask a similar 
question about mouse buttons, or other input (or output!) devices.

But it's a good point.  There should be some sort of callback to inform 
HID drivers that their device has been reset, so they could reset 
whatever internal state they are maintaining.

This sounds like something going way beyond usbhid, though.  And it 
probably would not crop up very often, so it wouldn't get much testing.  
Liam's computer seems to be pretty unusual.

Alan Stern