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

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

[Gordon Chen]

Hi Mario, Shyam, Mathias,

I'm reporting what looks like an interaction between AMD client SoC idle
power management (Data Fabric / SOCCLK) and low-latency isochronous USB
DMA, on a Ryzen 9 9955HX3D (Fire Range, Zen5) laptop. It reproduces on any
AMD Zen4/5 client I or others have tried, with any USB audio interface;
there is an open community bug with several different-vendor devices [1].

I have a strong differential pointing below the OS, but no way to read DF
C-state residency on this platform to confirm -- hence this mail. Questions
are at the end.

Symptom
-------
USB audio playback has frequent audible clicks, and after ~10-30 min of
continuous playback an occasional full stall. Each click maps 1:1 (time-
aligned) to a short isochronous OUT URB; at the packet level these are
iso_frame_desc[i].status = -EXDEV (COMP_MISSED_SERVICE_ERROR) -- the xHCI
controller missed servicing a 125 us microframe. urb->error_count stays 0
and nothing reaches dmesg; you have to look at per-packet status or count
short OUT URBs. The stall is the same fault at its extreme: on an implicit-
feedback device, a whole errored capture URB starves the OUT ring until
re-plug.

What I tried (all ineffective except the last)
----------------------------------------------
  cpu_dma_latency = 0 (PM QoS, verified locked)        no change
  cpuidle: all C-states disabled                       no change
  cpufreq governor = performance                       no change
  amdgpu power_dpm_force_performance_level = high       no change
  stress-ng --cpu 16 (pure compute, little mem traffic) no change
  stress-ng --stream  (sustained memory bandwidth)     misses -> 0

So CPU residency/frequency is not the lever; sustained memory-controller
traffic is. Reading SoC clock DPM (amdgpu pp_dpm_socclk / pp_dpm_mclk):
idle and under --cpu it sits at socclk 400 MHz / mclk 1600 MHz; under
--stream it jumps to socclk 1200 / mclk 2800.

This points away from clock frequency as the lever: a single --stream
worker already pins socclk=1200 / mclk=2800, yet the misses persist; it
takes several workers of continuous traffic before they drop to zero. So
what tracks the fix is not the clock the SoC reaches, but the amount of
sustained memory-controller traffic. My working hypothesis is that the
Data Fabric idles into a low-power state between the sparse isochronous
transactions, and that the wake/traversal latency on the next microframe
can then exceed the 125 us deadline -- with only traffic dense enough to
keep the fabric out of that state avoiding it. I cannot confirm that from
the OS (I have no way to read DF C-state residency here), so I would
welcome a sanity check on the mechanism; the measurements above are what
I am confident of.

I could not reach this from the OS: profile_peak / force=high do not raise
socclk (ignored for an otherwise-idle iGPU), and a manual pp_dpm_socclk /
pp_dpm_mclk write is rejected with -EINVAL. The BIOS on this laptop exposes
no "DF C-States" / "Power Supply Idle Control" option.

Reproducer
----------
Any AMD Zen4/5 client + any USB audio interface, playing continuously:

  # count short OUT URBs (= missed-service events); nominal is the device's
  # full OUT packet size (768 bytes for the Flow 8 at 48 kHz / 4 ch)
  bpftrace -e 'kprobe:snd_complete_urb {
    $u = (struct urb *)arg0;
    if ((($u->pipe >> 7) & 1) == 0 && $u->actual_length < 768) { @miss++; }
  }'

  # while watching: cat /sys/class/drm/cardN/device/pp_dpm_socclk
  # baseline:           misses > 0,  socclk pinned at 400 MHz
  # with stress-ng --stream 4 running:  misses 0,  socclk 1200 MHz

Questions
---------
 1. Is this a known interaction between DF idle power state (DF C-states /
    SOCCLK gating) and latency-sensitive isochronous DMA on client SoCs --
    an erratum or documented behaviour?

 2. Is there a supported way to hold the Data Fabric out of its deep idle
    state (or set a fabric-active floor) while a latency-sensitive iso USB
    endpoint is streaming -- a kernel interface (amd_pmc / amd_node?), or a
    firmware/PMFW setting -- short of burning memory bandwidth?

 3. If not, what telemetry would help characterize this (amd_pmc STB dump?
    specific SMN / DF P-state or C-state registers? a debugfs)? I'm happy
    to build an instrumented kernel and test patches.

Related: the extreme stall case (whole-URB error on the implicitly-fed OUT
ring) is separately handled in snd-usb-audio by a Flow 8 quirk that emits
silence instead of hanging (commit a23812004228). That only papers over the
hang and does nothing about the clicks, which are the subject here.

System: Ryzen 9 9955HX3D (Fire Range, Zen5, 16C/32T), AMD xHCI, iGPU
smu_v13_0_0 (0x13c0); kernel 7.0.10 (CachyOS, close to mainline for
usb / xhci / amd power-management).

Thanks,
Gordon Chen

[1] https://github.com/CachyOS/linux-cachyos/issues/665

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

[Mathias Nyman]

On 6/1/26 10:38, Gordon Chen wrote:
> Hi Mario, Shyam, Mathias,
> 
> I'm reporting what looks like an interaction between AMD client SoC idle
> power management (Data Fabric / SOCCLK) and low-latency isochronous USB
> DMA, on a Ryzen 9 9955HX3D (Fire Range, Zen5) laptop. It reproduces on any
> AMD Zen4/5 client I or others have tried, with any USB audio interface;
> there is an open community bug with several different-vendor devices [1].
> 
> I have a strong differential pointing below the OS, but no way to read DF
> C-state residency on this platform to confirm -- hence this mail. Questions
> are at the end.
> 
> Symptom
> -------
> USB audio playback has frequent audible clicks, and after ~10-30 min of
> continuous playback an occasional full stall. Each click maps 1:1 (time-
> aligned) to a short isochronous OUT URB; at the packet level these are
> iso_frame_desc[i].status = -EXDEV (COMP_MISSED_SERVICE_ERROR) -- the xHCI
> controller missed servicing a 125 us microframe. urb->error_count stays 0
> and nothing reaches dmesg; you have to look at per-packet status or count
> short OUT URBs. The stall is the same fault at its extreme: on an implicit-
> feedback device, a whole errored capture URB starves the OUT ring until
> re-plug.
> 
> What I tried (all ineffective except the last)
> ----------------------------------------------
>    cpu_dma_latency = 0 (PM QoS, verified locked)        no change
>    cpuidle: all C-states disabled                       no change
>    cpufreq governor = performance                       no change
>    amdgpu power_dpm_force_performance_level = high       no change
>    stress-ng --cpu 16 (pure compute, little mem traffic) no change
>    stress-ng --stream  (sustained memory bandwidth)     misses -> 0
> 
> So CPU residency/frequency is not the lever; sustained memory-controller
> traffic is. Reading SoC clock DPM (amdgpu pp_dpm_socclk / pp_dpm_mclk):
> idle and under --cpu it sits at socclk 400 MHz / mclk 1600 MHz; under
> --stream it jumps to socclk 1200 / mclk 2800.
> 
> This points away from clock frequency as the lever: a single --stream
> worker already pins socclk=1200 / mclk=2800, yet the misses persist; it
> takes several workers of continuous traffic before they drop to zero. So
> what tracks the fix is not the clock the SoC reaches, but the amount of
> sustained memory-controller traffic. My working hypothesis is that the
> Data Fabric idles into a low-power state between the sparse isochronous
> transactions, and that the wake/traversal latency on the next microframe
> can then exceed the 125 us deadline -- with only traffic dense enough to
> keep the fabric out of that state avoiding it. I cannot confirm that from
> the OS (I have no way to read DF C-state residency here), so I would
> welcome a sanity check on the mechanism; the measurements above are what
> I am confident of.
> 
> I could not reach this from the OS: profile_peak / force=high do not raise
> socclk (ignored for an otherwise-idle iGPU), and a manual pp_dpm_socclk /
> pp_dpm_mclk write is rejected with -EINVAL. The BIOS on this laptop exposes
> no "DF C-States" / "Power Supply Idle Control" option.
> 
> Reproducer
> ----------
> Any AMD Zen4/5 client + any USB audio interface, playing continuously:
> 
>    # count short OUT URBs (= missed-service events); nominal is the device's
>    # full OUT packet size (768 bytes for the Flow 8 at 48 kHz / 4 ch)
>    bpftrace -e 'kprobe:snd_complete_urb {
>      $u = (struct urb *)arg0;
>      if ((($u->pipe >> 7) & 1) == 0 && $u->actual_length < 768) { @miss++; }
>    }'
> 
>    # while watching: cat /sys/class/drm/cardN/device/pp_dpm_socclk
>    # baseline:           misses > 0,  socclk pinned at 400 MHz
>    # with stress-ng --stream 4 running:  misses 0,  socclk 1200 MHz
> 
> Questions
> ---------
>   1. Is this a known interaction between DF idle power state (DF C-states /
>      SOCCLK gating) and latency-sensitive isochronous DMA on client SoCs --
>      an erratum or documented behaviour?
> 
>   2. Is there a supported way to hold the Data Fabric out of its deep idle
>      state (or set a fabric-active floor) while a latency-sensitive iso USB
>      endpoint is streaming -- a kernel interface (amd_pmc / amd_node?), or a
>      firmware/PMFW setting -- short of burning memory bandwidth?

If xHCI supports Latency Tolerance Messaging Capability (LTC) bit in the
HCCPARAMS1 register then it should be capable of accepting latency tolerance
messages from USB3 devices, keep track of the shortest tolerated value, and
send it forward to the fabric (if PCIe then it should use PCIe LTR messages)
xHCI driver does not take part in this.
see xHCI specs 4.13.6

LTC capability in xHCI also supports driver adding custom Latency values that
the xHC hardware should take into account when calculating shortest tolerated
latency.
xhci driver does not (yet) support this, but could be worth hacking some PoC
code together to see if this works.
   
HCCPARAMS register can be read via debugs from:
debug/usb/xhci/<address>/reg-cap

Thanks
Mathias

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

[Gordon Chen]

Hi Mathias, and Mario / Shyam,

Thanks Mathias -- the LTR/LTC angle is very helpful. It points at exactly
the kind of "tell the fabric to stay awake for this stream" mechanism I was
looking for, without having to burn memory bandwidth.

Following your pointer I read the capability registers via debugfs (reg-cap)
on the controller the device sits behind (0000:6b:00.3):

    HCCPARAMS1 = 0x0120ffc5   ->  bit 6 (LTC) = 1

So this xHC does advertise the Latency Tolerance Messaging Capability.

One constraint rules out the first path you described, though: the device
(Behringer Flow 8) is a USB 2.0 high-speed device -- speed = 480 Mbps,
bcdUSB 2.00, no BOS descriptor and no LTM support advertised. It therefore
never emits USB3 LTM messages, so there is nothing for the xHC to aggregate
from the device side, and I'd expect it to forward a permissive (large)
tolerance upstream by default -- which would let the fabric idle freely.

That leaves the second path you mentioned: the driver injecting a custom
latency value that the xHC factors into the shortest-tolerated-latency it
forwards. Since the xhci driver doesn't implement that yet, a few questions
before I hack a PoC together:

  - Which mechanism in the spec does this map to (4.13.x)? Is it a value the
    driver writes to a register / context that the xHC then uses for its
    upstream LTR, or is it per-device / per-endpoint? A pointer to the exact
    field would save me a lot of guessing.

  - Is there any in-tree precedent or WIP I should base the PoC on?

I'm happy to write and test it -- I have a 1:1 reproducer (count short OUT
URBs while playing audio), so I can tell immediately whether forcing a small
tolerance makes the missed-service events disappear.

And for Mario / Shyam, the other half of the chain: assuming the xHC does
forward a small latency tolerance upstream as a PCIe LTR message, does the
AMD client SoC's Data Fabric honor PCIe LTR to constrain its idle / DF
C-state entry? Or is DF idle gating independent of PCIe LTR on these parts?
That determines whether the whole approach can work at all -- the xHCI side
can express the requirement, but only if the fabric acts on it.

(As a lighter-weight variant I'm also looking at whether writing an
aggressive LTR value directly at the PCIe layer for the xHC function has any
effect -- but that hinges on the same does-DF-honor-LTR question.)

Thanks again,
Gordon Chen

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

[Gordon Chen]

Hi all,

A quick correction and a sharper question after probing the PCIe side.

I checked the controller's PCIe config (lspci -vvv): the xHC function
(0000:6b:00.3) has no Latency Tolerance Reporting extended capability at all
and reports DevCap2 LTR-. Its upstream root port (00:08.1) is LTR- as well.
So the PCIe-layer variant I floated in my last mail is a dead end -- there
is no LTR register to write, and neither the endpoint nor the root port
advertises the mechanism.

That leaves an apparent contradiction I'd appreciate help squaring:

  - USB/xHCI layer: HCCPARAMS1 LTC = 1 (the controller advertises Latency
    Tolerance Messaging Capability).
  - PCIe layer: the same function is LTR- (no LTR capability at all).

So if I issue a Set LTV command (the driver-injected path you mentioned),
where does the xHC actually forward that aggregated tolerance value to the
fabric, given it has no PCIe LTR egress? Is there an internal sideband path
to the DF on these integrated AMD controllers, or does LTC only affect USB
link power states on this silicon -- in which case Set LTV would never reach
the Data Fabric?

If it's an internal/sideband path (Mario / Shyam?), a Set LTV PoC is still
worth trying. If LTC is purely USB-link-scoped here, it won't touch the DF
idle problem and I should look elsewhere. That distinction decides whether I
write the PoC at all.

Thanks,
Gordon Chen

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]

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