Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #94764

Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113)

Cross-posted to 2 groups.

Show all headers | View raw

Hi,


I hit the same regression on a third device vendor. The bisect result in
this thread is the right culprit, and I think I can add the missing piece:
why this commit breaks exactly this class of devices, and why so many
different interfaces regressed at once.


Affected device here: Topping E2x2 (USB ID 152a:8752, XMOS/Thesycon
UAC2 implementation), connected at high speed.


Symptoms on linux-image-6.12.115+deb13.1-amd64 (6.12.115-2):


 - The card enumerates and binds to snd-usb-audio normally; there is not a
   single error in dmesg.
 - PipeWire/WirePlumber see it and it can be selected as the default sink.
 - The PCM opens, configures and triggers successfully:


     access: MMAP_INTERLEAVED, format: S32_LE, channels: 2, rate: 48000
     period_size: 512, buffer_size: 32768
     state: RUNNING


 - But nothing is ever transferred. While playing, sampled over 5 seconds:


     delay    : 4608   (constant)
     hw_ptr   : 0      (never advances)
     appl_ptr : 4608


   Not a single URB completes, and still no error is logged.
 - Booting 6.12.113-1 restores playback immediately.


This is the same picture as #1152963 (Audient iD4: "state: RUNNING, but
hw_ptr stays at 0"), and consistent with #1152962.


Why implicit-feedback devices are the ones affected


The bad commit, ef5749ef8b30 ("ALSA: usb-audio: Prevent excessive number of
frames"), added this to prepare_playback_urb() in sound/usb/pcm.c:


    counts = snd_usb_endpoint_next_packet_size(ep, ctx, i, avail);
    if (counts < 0 || frames + counts >= ep->max_urb_frames)
            break;


However ep->max_urb_frames is assigned in only one branch of
snd_usb_endpoint_set_params() (sound/usb/endpoint.c):


    if (usb_pipein(ep->pipe) || ep->implicit_fb_sync) {
            ...
            ep->nurbs = MAX_URBS;
            /* ep->max_urb_frames is NOT initialized here */
    } else {
            ...
            ep->max_urb_frames = DIV_ROUND_UP(ep->cur_period_frames,
                                              urbs_per_period);
    }


A playback endpoint driven by implicit feedback (usb_pipein() false and
implicit_fb_sync true; see snd_usb_endpoint_implicit_feedback_sink())
takes the first branch, so ep->max_urb_frames keeps its kzalloc() value of
zero. The new condition then degenerates to "frames + counts >= 0", which
is always true, so the loop breaks at i == 0, frames stays 0, and the
function returns -EAGAIN:


    if (!frames) {
            err = -EAGAIN;
            goto unlock;
    }


No URB is ever submitted. Playback is dead silent, and nothing is printed
to dmesg, because -EAGAIN here is the normal retry path.


This also explains the spread of the reports: every interface whose
playback endpoint uses implicit feedback regressed, regardless of vendor
(MOTU, Audient, Behringer, Topping, ...), while devices that do not use it
are unaffected. It may also explain why different reports show different
low-level errors (EIO/EPIPE in #1152888, a plain hang in #1152963) - same
code path, different manifestation.


The fix is already upstream


    70b4db7d2581 "ALSA: usb-audio: Use the right limit for PCM OOB check"
    (Takashi Iwai, 2026-01-21, eight days after ef5749ef8b30)


which replaces the ep->max_urb_frames test with a bound based on the real
buffer:


    if (counts < 0 ||
        (frames + counts) * stride > ctx->buffer_size)
            break;


06be918062ad ("Bound packet copies by the PCM buffer size", 2026-10-26)
later adds subs->buffer_bytes as a second bound.


Debian 6.12.115-2 appears to carry ef5749ef8b30 but not its immediate
follow-up. I verified this against the shipped binaries: unpacking
snd-usb-audio.ko.xz from both installed kernels and comparing symbol sizes,
prepare_playback_urb() is the only function that changed between 6.12.113
and 6.12.115 (1630 -> 1653 bytes), and its disassembly contains the
ep->max_urb_frames comparison.


For 6.12.y, if ctx->buffer_size is not available there (I could not find it
in 6.12.115's pcm.c), subs->buffer_bytes already exists and gives an
equivalent bound; alternatively the check can simply be skipped when
ep->max_urb_frames is zero.


Happy to test a candidate kernel build.


Side note: I do not think #1152914 is the same issue - that one fails during
probe ("clock source 41 is not valid") rather than after streaming starts.


Note: the root cause analysis above was carried out jointly by the reporter
and an LLM-based assistant, and was verified against the shipped Debian
kernel binaries and the corresponding upstream sources.


Thanks,
smg <smgdream@foxmail.com>

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113) Benjamin Scherrer <benjamin@wagnerbrutal.de> - 2026-11-02 22:20 +0100
  Processed: Re: Bug#1152888: Regression: MOTU M4 USB audio  playback fails with EIO on Linux 6.12.115 (works on 6.12.113) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-11-03 17:20 +0100
  Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113) Salvatore Bonaccorso <carnil@debian.org> - 2026-11-03 17:20 +0100
    Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113) Benjamin Scherrer <benjamin@wagnerbrutal.de> - 2026-11-03 23:50 +0100
  Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113) Sebastian Kiesel <sebastian-debian-reportbug@skiesel.de> - 2026-11-03 17:40 +0100
  Bug#1152888:  Michele Zelioli <michele.zelioli@ik.me> - 2026-11-03 21:50 +0100
  Bug#1152888: MOTU M2 also affected by 6.12.115 USB audio regression Christopher Ludwin <cjludwin@pm.me> - 2026-11-03 23:10 +0100
  Bug#1152888: Regression: MOTU M4 USB audio playback fails with  EIO on Linux 6.12.115 (works on 6.12.113) "smg" <smgdream@foxmail.com> - 2026-11-04 04:20 +0100
  Processed: Re: Bug#1152888: Regression: MOTU M4 USB audio  playback fails with EIO on Linux 6.12.115 (works on 6.12.113) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-11-04 06:00 +0100
  Bug#1152888: Regression: MOTU M4 USB audio playback fails with  EIO on Linux 6.12.115 (works on 6.12.113) "smg" <smgdream@foxmail.com> - 2026-11-04 16:20 +0100
  Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113) Benjamin Scherrer <benjamin@wagnerbrutal.de> - 2026-11-04 17:30 +0100
  Bug#1152888: Regression: MOTU M4 USB audio playback fails with EIO on Linux 6.12.115 (works on 6.12.113) Sebastian Kiesel <sebastian-debian-reportbug@skiesel.de> - 2026-11-04 18:50 +0100
  Processed: Re: Bug#1152888: Regression: MOTU M4 USB audio  playback fails with EIO on Linux 6.12.115 (works on 6.12.113) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-11-05 07:50 +0100

csiph-web