Re: [BUG] xHCI: AMD Strix Halo [1022:158b] isochronous full-duplex USB audio instability (frame active: -18)

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

On Sun, 6 Sep 2026 20:27:54 +0200, Ingo Haenlein wrote:
> Hi Michal, hi Mathias,
> 
> Quick update and a new regression on the same Strix Halo case.
> 
> Root cause, confirmed
> ----------------------
> DF/fabric C-state exit latency on the IRQ-handling core. Spent
> several more months on this: PM-QoS is not enforced by acpi_idle,
> governor/EPP tuning made no difference, pinning FCLK/SOCCLK made no
> difference either. The only thing that fully fixes it is a hidden
> AMD "SoC/Uncore OC Mode" BIOS bit - confirmed working by someone else
> on a different vendor's board - but that option is locked down on
> this HP firmware and too risky to unlock without a recovery path, so
> that's not viable for me.
> 
> Mitigation
> -----------
> Two isolated cores (CPU16/17, via isolcpus/nohz_full/rcu_nocbs) with
> the xHCI interrupt (0000:c5:00.4) pinned to one of them, plus a
> small script that switches those two cores to POLL (disabling all
> deeper C-states) only while an audio stream is active, and back to
> normal idle otherwise.

Odd, I thought the issue was caused by the xHC experiencing latency
while fetching OUT data from RAM, not by IRQ handling.

Maybe you are affected by the broken isoc scheduling? Try v7.3 RC,
it may work better now.

> On 7.1.11, with this mitigation running, a Missed Service Error burst
> happened at stream start, then nothing - no further errors, no
> XRuns, no endpoint restarts, for the rest of the session. This held
> across every buffer size I tested (64/96/128/192/256 samples
> @48kHz) and under sustained DSP load.
> 
> New regression
> ---------------
> Same mitigation, same hardware, nothing changed on my end. On
> 7.2.2/7.2.3, that's no longer true: I now get audible ALSA/PipeWire
> XRuns and full endpoint stop/restart cycles (playback + capture PCM
> stopped and restarted), both at stream start and during ongoing
> playback (e.g. while Bitwig or Spotify is running). This did not
> happen on 7.1.11 with the identical setup.

Even with several ms per period, or only with short periods?

> I traced the kernel change in between to commit 87dbc3fa08fc ("usb:
> xhci: Handle bogus TRB pointers in Missed Service Error events", now
> in 7.2.2/7.2.3, Fixes: d0b619599e52).
> 
> Confirmed by direct A/B, same hardware/config/mitigation:
> 
> - linux-zen 7.1.11: start burst, then quiet - no XRuns, no endpoint
>    restarts
> - linux-zen 7.2.2 / 7.2.3: XRuns and endpoint restarts, reproducible,
>    both at start and during playback

That sounds like guesswork, or was it confirmed by reverting the
suspect commit on 7.2? It should revert cleanly.

This commit only makes a difference in how missed service is handled
once it has already occurred. And only on some buggy hardware, or at
least such was the goal.

Regards,
Michal