Re: xhci_hcd: AMD Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8] dies on resume from suspend

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

On Sun, 10 May 2026 17:29:26 +0100, Martin Alderson wrote:
> 1. The timing is during suspend in every single failure I have logs
> for. I went back through 7 weeks of persistent journals and pulled the
> context around every "HC died" event. All 9 failures show the same
> sequence:
> 
>   xhci_hcd 0000:0f:00.0: xHCI host not responding to stop endpoint command
>   xhci_hcd 0000:0f:00.0: xHCI host controller not responding, assume dead
>   xhci_hcd 0000:0f:00.0: HC died; cleaning up
>   PM: suspend devices took 5.5--6.1 seconds      <-- elevated
>   amdgpu 0000:03:00.0: MODE1 reset
>   ACPI: PM: Preparing to enter system sleep state S3
> 
> So it's reliably during suspend, before S3 entry, and the elevated
> "suspend devices took" matches the 5s xHCI stop-endpoint timeout. A
> clean suspend on the same boot takes ~0.46s.

The S3 state probably doesn't matter, chances are that it would also
happen with s2idle or hibernation.

Could you enable dynamic debug before every suspend (or permanently
on every boot) and collect a dmesg log of this happening again?
And maybe also a snapshot of debugfs directory after resume but before
unbinding xhci_hcd. These may contain clues what triggered it.

echo 'module xhci_hcd +p' >/proc/dynamic_debug/control
zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0f:00.0

> 2. No BIOS upgrade. ASUS PRIME B650-PLUS BIOS version 3263 dated
> 2025-06-09 across every boot from 2026-03-02 to 2026-05-08 (42 boots).
> 
> 3. Re "any new USB device": yes, and it correlates exactly. A 4-port
> USB hub appeared on bus 1 (controller 0c:00.0, AMD 600 Series USB 3.2)
> on 2026-03-16, with a USB mass-storage device behind it on port 4. It's
> the hub built into a new monitor I added around then. Per-boot
> presence:
> 
>   2026-03-02 to 2026-03-16: NO hub, NO flash drive, ~12 6.17.1
>                             suspends, 0 failures
>   2026-03-16+:              hub + flash drive present
>   2026-03-22 to 2026-03-28: 7.0-rc4 with hub present, 13 suspends,
>                             0 failures
>   2026-03-28+:              7.0-rc5+, failures begin
>   2026-04-18 to 2026-04-25: 6.17.1 (retry, with hub still present),
>                             10 suspends, 2 failures -- same kernel
>                             that was clean in March
> 
> The hub is on a different xHCI from the one that dies (0c:00.0 vs
> 0f:00.0), but they're sibling controllers on the same AMD SoC, so
> shared power/ACPI domains seem plausible.

That's over a week from first connection to the first failure.
And these are separate chips of different type, the 600 series chipset
is not part of the CPU while the broken one is the CPU I/O die AFAIK.

May be a coincidence. I would sooner suspect changes to devices on the
affected bus to be responsible.

Regards,
Michal