Re: xhci_hcd 0000:0c:00.0 dies with "Abort failed to stop command ring: -110" exactly 24s post-init, tunneled USB4 xHCI behind Goshen Ridge (ASUS ThunderboltEX 4) + CalDigit TS4

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 9/22/26 07:26, Mika Westerberg wrote:
> Hi,
> 
> On Mon, Sep 21, 2026 at 07:25:53PM -0400, Ben wrote:
>> Mika,
>>
>> I've attached the dmesg output from cold boot, the output of tbdump,
>> and a copy of my boot record for a sanity check. I plugged my
>> mouse/keyboard driectly into the motherboard as I tried once before
>> this and did not have access to USB devices through the dock.
> 
> Thanks! Yeah I can see that the xHCI is enumerated just fine:
> 
> [    0.444810] xhci_hcd 0000:0c:00.0: xHCI Host Controller
> [    0.444815] xhci_hcd 0000:0c:00.0: new USB bus registered, assigned bus number 1
> [    0.446007] xhci_hcd 0000:0c:00.0: hcc params 0x20007fc1 hci version 0x110 quirks 0x0000000000009810
> [    0.446448] xhci_hcd 0000:0c:00.0: xHCI Host Controller
> [    0.446450] xhci_hcd 0000:0c:00.0: new USB bus registered, assigned bus number 2
> [    0.446452] xhci_hcd 0000:0c:00.0: Host supports USB 3.1 Enhanced SuperSpeed
> 
> but then later on it is not accessible anymore:
> 
> [   24.964042] xhci_hcd 0000:0c:00.0: Abort failed to stop command ring: -110
> [   24.964050] xhci_hcd 0000:0c:00.0: xHCI host controller not responding, assume dead
> [   24.964053] xhci_hcd 0000:0c:00.0: HC died; cleaning up
> [   24.964071] xhci_hcd 0000:0c:00.0: Error while assigning device slot ID: Command Aborted
> [   24.964075] xhci_hcd 0000:0c:00.0: Max number of devices this xHCI host supports is 64.
> 
> It could be that it went into runtime suspend before that. One thing you
> could try is to connect USB3 device to the dock, like memory stick or so.
> That would prevent xHCI from entering runtime suspend.
> 
>>> Are you able to see if the link is USB4 or TB3? Can you do the same now
>>> with Linux, boot with the dock connected and share full dmesg?
>>
>> In Windows, I check with the Intel Thunderbolt Control Center, which
>> indicated the link was TB4. I then checked the Device manager and the
>> PCIE device indicated that it was taking up enough of the bus to
>> support that, though I was not able to take a screenshot. I could
>> check again if it would be helpful
> 
> Can you see the 0c:00.0 xHCI in the device manager? I would expect yes and
> then this ends up just being Linux specific issue with the xHCI on GR. I'm
> adding Mathias in case he has any ideas.

It fails on the very first command xHCI is asked to run.
This command is queued after a usb device connection is detected.

It behaves as interrupts aren't working properly, or then xHC isn't
running at all.
Looks like this xHC host supports D1 and D2 states, not sure if it's relevant.

"Abort failed to stop command ring: -110" means command was queued 10seconds
earlier. If there were usb devices connected to this host at boot then it still
took way too long to detect them (~12 seconds).

Missing/blocked xHC interrupt would be my best guess.

Are there any interrupts for this xHCI device in /proc/interrupts?

Can you take snapshot copy of some xHC rings and registers a couple seconds before
the crash? following directories would be interesting, (including all files,
especially the 'trbs' ones):

/sys/kernel/debug/usb/xhci/0000:0c:00.0/event-ring/
/sys/kernel/debug/usb/xhci/0000:0c:00.0/command-ring/

The reg-op file could also be useful:

/sys/kernel/debug/usb/xhci/0000:0c:00.0/reg-op


The event ring content should show if xHC processed the command or not.
i.e. is xHC not running, thus failing to process the command, or are
interrupts not triggered on successfully completed commands.

Thanks
Mathias