Re: USB-audio isochronous Missed Service Errors on AMD Zen5 client (Fire Range) -- Data Fabric idle C-state? No OS-level knob found

[Ingo Haenlein <ingo.haenlein@gmx.de>]

Hi Gordon,

I am reporting a related data point from an AMD Strix Halo system
(HP ZBook Ultra G1a, Ryzen AI MAX+ PRO 395, xHCI [1022:158b] on Bus 007).

Michal Pecio pointed me to your thread from my linux-usb report:
https://lore.kernel.org/linux-usb/48aadb68-b4d1-4dd6-82ca-76d0846b4ae1@gmx.de/

Same error class: COMP_MISSED_SERVICE_ERROR / -EXDEV on isochronous USB
audio endpoints, sporadic bursts during continuous full-duplex streaming,
no DMA error. Same LTC/LTR constellation: HCCPARAMS1 = 0x0118ffc5
(LTC=1), but DevCap2: LTR- on both the xHCI function (c5:00.4) and the
upstream internal GPP bridge (00:08.3).

One divergence from your Fire Range result:

stress-ng --stream does not suppress the issue on Strix Halo, neither
with 1 nor with 32 workers. Under full --stream load, amdgpu_top shows
GFX_MCLK staying at 1000 MHz -- which is the hardware ceiling on this
platform (LPDDR5 400-1000 MHz, per amdgpu_top header). Fire Range
reaches 2800 MHz under --stream, which appears to be what keeps the DF
out of the problematic idle state. On Strix Halo that lever does not
exist: --stream cannot push MCLK beyond 1000 MHz, so the DF can
apparently still reach the idle state that causes ISO ring loss.

SOCCLK on Strix Halo shows only an average (~650-666 MHz) via
amdgpu_top; Cur. reads N/A MHz -- no current-state visibility from the
OS, unlike what you can read on Fire Range.

So on Strix Halo: same error class, same LTC/LTR contradiction, but
the --stream workaround is structurally ineffective due to the lower
MCLK ceiling. Your questions to AMD (DF idle / ISO DMA interaction,
OS-accessible knob) apply here as well.

Do you have any update from AMD on the questions you raised -- in
particular whether Set LTV reaches the DF via sideband, and whether
there is an OS-accessible knob to hold the fabric active during ISO
streaming?

Regards,
Ingo