Re: [PATCH 0/2] xhci: handshake timeout overrun and configure endpoint hang on device disconnect

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

On Wed, 30 Sep 2026 18:17:50 +0800, Henry Tseng wrote:
> This series addresses two problems found while debugging an AMD Raven
> USB 3.1 xHCI (1022:15e0) that gets declared dead when a USB storage
> enclosure is unplugged. During teardown a command fails to complete,
> aborting the command ring also fails, and the whole host is declared
> dead, taking unrelated devices on other root ports down with it:
> 
>   xhci_hcd 0000:0c:00.3: Command timeout, USBSTS: 0x00000010 PCD
>   xhci_hcd 0000:0c:00.3: Abort command ring
>   xhci_hcd 0000:0c:00.3: Abort failed to stop command ring: -110
>   xhci_hcd 0000:0c:00.3: xHCI host controller not responding, assume dead

Sounds like UAS, because I doubt that similar problems with ordinary
bulk endpoints could remain unknown for long.

I wonder if the kernel may be doing something crazy or out of spec
to deserve "undefined xHC behavior". See notes in xHCI 4.6.6, similar
requirements are also spelled in 4.6.4.

Is this easily reproducible? Could you send debugfs of this failure,
preferably before the "assume dead" message? See also my patch below.

zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0c:00.3/

> Reproduced on mainline v7.3-rc5:

Any other known affected or unaffected releases?

> Patch 2 fixes the host death on disconnect. The command that never
> completed is a configure endpoint command issued during teardown of a
> device behind the disconnected root port, right before disable slot for
> the same slot. Skip it when the roothub port is gone, as
> xhci_check_bandwidth() already does when the host is being removed.

That's not exactly the same, becasue with the xHC gone, we need not
worry what happens later. You found that Disable Slot works, so that's
OK, at least with this HC. Not sure about Reset Device, in case it's
not a disconnection but SS.Inactive due to link error.

> Patch 1 is an independent handshake overrun noticed during the same
> debugging, and does not fix the disconnect hang on its own. The
> command abort handshake has a 5 s timeout but took 15.8 s with
> interrupts disabled.

This patch should fix the "interrupts disabled" part:
https://lore.kernel.org/linux-usb/20260824095944.1c8335fa.michal.pecio@gmail.com/

And yes, the timeout is actually longer than intended. Interesting that
this is apparently a regression due to core changes, not an xhci-hcd
bug. It's possible that other drivers were similarly affected.

Regards,
Michal