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 Thu, 28 May 2026 12:52:16 +0100, Martin Alderson wrote:
> Caught a fresh failure on kernel 7.0.9-205.fc44.x86_64 with xhci_hcd.dyndbg=+p:
> 
> Timeline (single suspend cycle):
> 
>   11:09:45  xhci_suspend: stopping usb1/3/5 port polling
>   11:09:50  xhci_hcd 0000:0f:00.0: xHCI host not responding to stop
> endpoint command
>   11:09:50  xhci_hcd 0000:0f:00.0: xHCI host controller not
> responding, assume dead
>   11:09:50  xhci_hcd 0000:0f:00.0: HC died; cleaning up
>   11:09:52  xhci_hcd 0000:0e:00.3: port resume event for port 1
> (keyboard wake)
> 
> 5-second gap between suspend start and HC died - the stop endpoint
> timeout you predicted.
> 
> Command ring state at death:
> 
>   0xffffe070: Stop Ring Command: slot 1 sp 1 ep 1 flags C   (completed)
>   0xffffe080: Stop Ring Command: slot 1 sp 0 ep 1 flags C   <- dequeue (stuck)

That's odd, I wouldn't expect further Stop EP commands for the same
endpoint after one with the SP flag. Not until the USB device resumes.
Mathias may have guessed right that there is some unexpected activity
concurrently with suspend.

>   0xffffe090: empty                                          <- enqueue
> 
>   enqueue - dequeue = 1 TRB pending
>   USBCMD = 0x0   USBSTS = 0x1 (HCHalted)
>   port01 portsc = 0x663  Link=U3 CCS PP PED
> 
> 
> I have the full snapshot: command-ring/event-ring TRB dumps, all xhci
> debugfs registers, dmesg with full dyndbg trace, and the kernel
> journal for the cycle. I'm not sure the best way to send it though if
> you need it?

I suppose the debugfs zip isn't very large so an attachment would be
fine, plus another attachment with dmesg from the beginning of suspend
attempt, or complete dmesg if it doesn't exceed a few MB. Preferably
with sub-second resolution timestamps, if you have them.

Regards,
Michal