Re: [PATCH] ALSA: usb-audio: reset a MIDI device whose input is stuck

[Takashi Iwai]

On Mon, 26 Oct 2026 13:57:51 +0100,
Stjepan Poljak wrote:
> 
> Switching a bus-powered USB keyboard off and on can be too quick for the
> hub to report a disconnect. The device comes back unconfigured at the old
> address, and its input endpoint then fails forever:
> 
>   - with -EPIPE, which snd_usbmidi_urb_error() logs and treats as
>     "continue", so the URBs are resubmitted at once and the log fills
>     with "urb status -32" every few milliseconds;
>   - or with -EPROTO/-ETIME/-EILSEQ, retried silently every 100 ms.
> 
> Either way the rawmidi device stays, reads never fail and no data ever
> arrives, so the instrument goes silent until the cable is replugged.
> 
> Retry a stalled input endpoint through the error timer like the other
> errors, and when input stalls, or keeps failing for 2 s with no
> successful URB, queue a USB reset. snd-usb-audio has no pre_reset or
> post_reset, so the reset unbinds and re-probes the card, and userspace
> sees an ordinary unplug and replug. A real unplug normally reaches
> disconnect() long before 2 s. If the host misses that as well, as
> dwc_otg does behind a hub, the input stalls and the reset finds no
> device, which ends in the same disconnect.
> 
> The queued reset is dropped without a word if usb_lock_device_for_reset()
> fails (e.g. -EBUSY when the device lock is held for over a second), so
> while input keeps failing, queue another one every 2 s.
> 
> Output endpoints are left as they are.
> 
> Tested on a Raspberry Pi 3B+ (dwc_otg, Raspberry Pi 6.12.61 kernel) with
> a Nektar Impact LX49+ (2467:2015) behind the on-board hub. Without this
> patch, switching the keyboard off and on left it silent, with "urb
> status -32" logged every few milliseconds. With it, each off/on cycle
> logged a single "MIDI input not recovering (urb status -32), resetting
> device", and the keyboard was re-enumerated and playing again 2.8-4.0 s
> later, including two cycles 9 s apart. Left switched off for 3 minutes,
> it was reset, disconnected cleanly and enumerated normally when switched
> back on. Unplugging the cable went the same way: the input stalled, the
> reset found no device and disconnected it, and plugging it back in
> enumerated it normally. No warnings while playing normally over about
> three hours.
> 
> Also tested on x86_64 (xHCI, 7.0 kernel): there the host sees both the
> off/on cycle and an unplug as ordinary disconnects, so no reset is
> queued and input resumes after re-enumeration as before.
> 
> Assisted-by: LLM
> Signed-off-by: Stjepan Poljak <stjepan.poljak@xxxxxxxxx>

This doesn't look like a problem to be worked around in the USB audio
driver side, but better to be addressed in the USB core, IMO.

Please try that, or ask USB guys.  If they find this should be rather
fixed in that way, I can reconsider and review again.


thanks,

Takashi