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

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

On Mon, 26 Oct 2026 13:39:42 -0700, Yiyu Zhou wrote:
> On Mon, 26 Oct 2026 12:15:44 +0100, Michal Pecio wrote:
> > I wonder if it's possible that usbhid driver requests a reset to
> > recover from errors and usbcore performs it blindly without paying
> > attention to connect status?  
> 
> I think that is what happens, and that 1f36cc9fa949 is what makes it
> reachable here.
> 
> Interfaces 0 and 1 bind before the device drops off, and the VT
> keyboard handler opens the keyboard interface right away, so its
> interrupt-in URB is running.  With 1f36cc9fa949 that URB is given back
> with -EPROTO and the resubmits fail with -ENODEV, so hid_io_error()
> keeps retrying and after 1 s schedules hid_reset(), which calls
> usb_queue_reset_device().  usb_reset_device() only checks for
> USB_STATE_NOTATTACHED, and the udev stays configured until hub_wq
> handles the connect change.  At boot hub_wq only gets back to port 1
> after the other ports (about 1.5 s after the disconnect in Dennis's
> dyndbg log), so the reset gets there first.  The device is back by
> then, so the port reset succeeds and the reset reuses the udev and the
> slot, ep0 ring included.

Yes, this seems plausible based on the input from Alan Stern. If reset
is requested before a USB2 reconnection but executed after it, then
hub_port_connect_change() sees (connect-change && enabled) port state
and it attempts to reuse ("resuscitate") the existing udev.

> On plain 7.3 the halted interrupt TD isn't given back until hub_wq
> handles the disconnect, so usbhid sees no error and never asks for a
> reset.  The device only comes back through the full disconnect at 56 s
> in Dennis's first log, which frees the slot and its ring.

Plausible too. But while the bug isn't triggered, it's still there.

Even on 7.3 without 1f36cc9fa949, when the failed URB is unlinked, it
seems that xhci_invalidate_cancelled_tds() marks its TDs as ready for
giveback without doing anything to prevent their execution. The EP is
expected never to run again and we are just lucky that nobody resets
the device before it's freed.

> Instead of repairing ep0 in place, could it stay blocked until Address
> Device has reloaded its context?

Not really, because EP0 must be ready for URBs before the device is
addressed, and the "BSR" flag is only legal on freshly enabled slots.

> If EP_DROP_PENDING stays set on ep0 until then, the new-scheme
> GET_DESCRIPTOR fails at once with -ENODEV, and
> usb_reset_and_verify_device() re-enumerates the device on a new slot,
> as after a real disconnect.

You seem to suggest that xhci-hcd should trick usbcore into abandoning
"resuscitation", right? I think that's a sort of complexity that the
world would be better off without, and it changes an intentional policy
of usbcore, so it's not suitable for an urgent stable fix.

The "right" thing to do here is to use Stop Endpoint and Set TR Dequeue
after Reset Device or Reset Endpoint (if applicable) and Set TR Dequeue
before Reset device, i.e. exclude EP0 from EP_DROP_PENDING logic.


Possibly the simplest way out, at least for the already released 7.3,
might be partly reverting the offending commits so as not to affect
USB2. The original VDEV_PORT_ERROR logic was exclusive to USB3 and the
problems which 7.3 was supposed to solve are also exclusive to USB3.

Is there any need for this to affect USB2, other than "just in case"?

Then there will be a few weeks to sort out remaining USB3 issues, which
mostly existed for a while and haven't bothered anybody.

Regards,
Michal