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, 21 Jun 2026 21:19:39 +0200, Ingo Haenlein wrote:
> [Sun Jun 21 20:44:14 2026] xhci_hcd 0000:c5:00.4: Miss service interval 
> error for slot 1 ep 1, set skip flag, skip now
> [Sun Jun 21 20:44:14 2026] xhci_hcd 0000:c5:00.4: Found td. Clear skip 
> flag for slot 1 ep 1.
> [Sun Jun 21 20:44:14 2026] xhci_hcd 0000:c5:00.4: Miss service interval 
> error for slot 1 ep 4, set skip flag, skip now
> [Sun Jun 21 20:44:14 2026] xhci_hcd 0000:c5:00.4: Found td. Clear skip 
> flag for slot 1 ep 4.
> [Sun Jun 21 20:44:14 2026] usb 7-1: frame 5 active: -18
> [Sun Jun 21 20:44:14 2026] usb 7-1: frame 6 active: -18
> [Sun Jun 21 20:44:14 2026] usb 7-1: frame 7 active: -18

OK, I see, it's "frame %d active" and I searched for "frame active".
Anyway, it's sound driver reporting EXDEV completions, as expected.

> Regarding the related thread you pointed me to:
> 
> https://lore.kernel.org/linux-usb/18b4e4f7089aa4f1.da8dbe994ae3bb77.445e21b98b0b205b@GordonMsi/
> 
> I checked my Strix Halo system against that LTC/LTR angle. I do not
> know whether it is the same root cause, but the error class looks
> similar: AMD client platform, USB audio isochronous traffic, xHCI
> missed-service / -EXDEV.
> 
> For xHCI 0000:c5:00.4:
> 
> /sys/kernel/debug/usb/xhci/0000:c5:00.4/reg-cap:
> 
> HCCPARAMS1 = 0x0118ffc5
> 
> Bit 6 is set, so xHCI HCCPARAMS1.LTC = 1.
> 
> However, lspci -vvv for the same xHCI function reports:
> 
> DevCap2: ... LTR-
> DevCtl2: ... LTR-
> 
> The upstream internal GPP bridge / root port 0000:00:08.3 also
> reports:
> 
> DevCap2: ... LTR-
> DevCtl2: ... LTR-
> 
> So on this Strix Halo system, xHCI advertises LTC, but standard PCIe
> LTR is not exposed on either the xHCI function or the upstream bridge.
> 
> I do not know whether Set LTV would reach the AMD fabric through an 
> internal sideband path on this integrated controller, or whether LTC
> is USB-link-scoped only here.

No one knows outside AMD and I'm not sure if it would matter anyway.

You can check if it's the same issue by running "stress-ng --stream",
which is supposed to "fix" it by keeping the SoC out of idle.

Regards,
Michal