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 Fri, 29 May 2026 00:06:33 +0100, Martin Alderson wrote:
> Hi, please see this attachment. Thanks for all your help!

Let's go through it.

grep xhci_suspend 20260528T100954Z/dmesg.txt 
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0e:00.4: xhci_suspend: stopping usb5 port polling.
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0c:00.0: xhci_suspend: stopping usb1 port polling.
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0e:00.3: xhci_suspend: stopping usb3 port polling.

Several HCs are suspending, but not 0000:0f:00.0. It seems that the
kernel is aware that "something" is still going on with its child USB
devices and it defers suspend until "something" finishes.

grep 0000:0f:00.0 20260528T100954Z/dmesg.txt 
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Cancel URB 00000000f24bbb02, dev 1, ep 0x83, starting at offset 0xfffe5c70
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: // Ding dong!
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Stopped on Transfer TRB for slot 1 ep 6
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Removing canceled TD starting at 0xfffe5c70 (dma) in stream 0 URB 00000000f24bbb02
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Set TR Deq ptr 0xfffe5c80, cycle 0
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: // Ding dong!
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: xhci_giveback_invalidated_tds: Keep cancelled URB 00000000f24bbb02 TD as cancel_status is 2
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Successful Set TR Deq Ptr cmd, deq = @fffe5c80
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: xhci_handle_cmd_set_deq: Giveback cancelled URB 00000000f24bbb02 TD
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Giveback URB 00000000f24bbb02, len = 0, expected = 32, status = -115
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: xhci_handle_cmd_set_deq: All TDs cleared, ring doorbell
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: // Ding dong!
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Stopped on No-op or Link TRB for slot 1 ep 4
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Stopped on No-op or Link TRB for slot 1 ep 2
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Stopped on No-op or Link TRB for slot 1 ep 0
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Set port 7-1 link state, portsc: 0x603, write 0x10661

Some device under 0000:0f:00.0 is suspended after having a 32 byte URB
unlinked from EP 3 IN and a few other (idle?) endpoints stopped.

[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: Cancel URB 00000000e74c9e14, dev 1, ep 0x0, starting at offset 0xffff4060
[Thu May 28 11:09:45 2026] xhci_hcd 0000:0f:00.0: // Ding dong!
[Thu May 28 11:09:50 2026] xhci_hcd 0000:0f:00.0: Command timeout, USBSTS: 0x00000000
[Thu May 28 11:09:50 2026] xhci_hcd 0000:0f:00.0: xHCI host not responding to stop endpoint command

Then some URB is unlinked from the same device's control endpoint with
no indication that the port has been resumed. Not 100% sure whether the
URB was submitted before or after device suspend. Either way, software
shouldn't do such things and your HW doesn't handle it gracefully.

It seems we will need to figure out how the offending URB gets there.
Can we identify the problematic device? Please post the output of:

lsusb -v |sed '/0000:0f:00.0/,/root hub/ !d'

Regards,
Michal