Re: [REGRESSION] usbhid -110 timeouts and reset loop for Keychron M5 (3434:d068) at boot since v7.3

[Michal Pecio <michal.pecio@gmail.com>]

Hi,

On Sun, 25 Oct 2026 01:10:27 +0200, Dennis Wissel wrote:
> On Sat, 24 Oct 2026 13:34:07 -0700, Yiyu Zhou wrote:
> > The fix is queued in Mathias's for-usb-linus branch as 1f36cc9fa949
> > ("xhci: give back all TDs when skipping endpoint reset after
> > disconnect") and applies cleanly to v7.3:  
> [...]
> > Could you test it?  If it fixes your case, please reply here so that
> > Mathias can add your Tested-by.  If it does not, reverting
> > 042aad8d0db6 and 7e0ef4332ed9 on v7.3 would show whether these
> > commits are involved.  
> 
> Thanks, I tested both on top of 7.3.0-4-cachyos, booting with the
> mouse plugged in each time.
> 
> 1) With 1f36cc9fa949: much better, but not completely fixed.
> 
> No reset loop anymore. After one disconnect and re-enumeration all four
> interfaces bind, and both the mouse and the NuPhy keyboard work.
> Before, the boot took about 3 minutes and both were dead.
> 
> But hub_wq still stalls for about 11 s after the first reset of the
> mouse. Other devices on the same controller (1-9.2, 1-14) are only
> enumerated after that. Just before the disconnect is handled, xhci
> prints three "not part of TD" messages for ep 0:
> 
> [    3.509460] usb 1-1: new full-speed USB device number 2 using xhci_hcd
> [    3.510626] hid-generic 0003:3434:D068.0001: input,hidraw0: USB HID v1.11 Mouse [Keychron Keychron M5 ] on usb-0000:00:14.0-1/input0
> [    3.510772] hid-generic 0003:3434:D068.0002: input,hidraw1: USB HID v1.11 Keyboard [Keychron Keychron M5 ] on usb-0000:00:14.0-1/input1
> [    4.973074] usb 1-1: reset full-speed USB device number 2 using xhci_hcd
> (nothing on the bus for 11 s)
> [   15.970122] xhci_hcd 0000:00:14.0: Event dma 0x0000000104205260 for ep 0 status 1 not part of TD at 00000001042052d0 - 00000001042052f0
> [   15.970767] xhci_hcd 0000:00:14.0: Event dma 0x0000000104205280 for ep 0 status 13 not part of TD at 00000001042052d0 - 00000001042052f0
> [   15.971131] xhci_hcd 0000:00:14.0: Event dma 0x0000000104205290 for ep 0 status 1 not part of TD at 00000001042052d0 - 00000001042052f0

That's not good, your HC seems to be executing stale URBs, probably
from before the device was reset. I suspect we reuse the default pipe
without recovering it from the broken state left by EP_DROP_PENDING. 
(Such bug may have existed since forever, but only in USB3 and cases
which seldom or never happen. 7.3 generalized it to more cases.)

But is USB core really resetting a device for which the hub has
reported disconnection? Something isn't as I would expect.

This could result in DMAR faults, but it didn't. Was IOMMU enabled?

> [   16.157121] usb 1-9.2: new high-speed USB device number 7 using xhci_hcd
> [   16.354120] usb 1-14: new full-speed USB device number 8 using xhci_hcd
> [   16.481086] usb 1-1: USB disconnect, device number 2
> [   16.894150] usb 1-1: new full-speed USB device number 11 using xhci_hcd
> [   17.026214] hid-generic 0003:3434:D068.000B: input,hidraw1: USB HID v1.11 Mouse [Keychron Keychron M5 ] on usb-0000:00:14.0-1/input0
> [   17.099110] hid-generic 0003:3434:D068.000C: input,hidraw9: USB HID v1.11 Keyboard [Keychron Keychron M5 ] on usb-0000:00:14.0-1/input1
> [   17.101019] hid-generic 0003:3434:D068.000D: hiddev100,hidraw10: USB HID v1.11 Device [Keychron Keychron M5 ] on usb-0000:00:14.0-1/input2
> [   17.103029] hid-generic 0003:3434:D068.000E: hiddev101,hidraw11: USB HID v1.11 Device [Keychron Keychron M5 ] on usb-0000:00:14.0-1/input3
> 
> 2) With 042aad8d0db6 and 7e0ef4332ed9 reverted (and without
> 1f36cc9fa949): exactly like 7.2.11. Interfaces 2 and 3 fail right away
> with -71, the device is reset once, no stall, no reset loop, and the
> mouse and keyboard work:
> 
> [    3.498259] usb 1-1: new full-speed USB device number 2 using xhci_hcd
> [    3.525104] usbhid 1-1:1.2: can't add hid device: -71
> [    3.525732] usbhid 1-1:1.3: can't add hid device: -71
> [    4.981085] usb 1-1: reset full-speed USB device number 2 using xhci_hcd
> [    5.167055] usb 1-9.2: new high-speed USB device number 7 using xhci_hcd
> [    5.352064] usb 1-14: new full-speed USB device number 8 using xhci_hcd

Not sure if I want to ask you to repro the failure on 7.3+1f36cc9fa949
unless you are sure that IOMMU is in good order or don't mind this
system potentially getting random junk DMA'd to a random place in RAM.

But can you post what happens on 7.2 with xhci_hcd and usbcore dynamic
debug enabled?

And BTW, the previous commit in the series (e3d757dc9257) also creates
problems which are fixed by the later ones, but those would be more of
a nuisance than corruption risk.

Regards,
Michal