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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Tue, Sep 15, 2026 at 11:01:20PM -0400, Ben wrote:
> Hello,
> 
> I've tested the plug after boot method, and it seems like it is working to get
> the dock full resources and stay stable.

Okay.

> For the second question: 
> It appears to me like the dock's xHCI is showing up as a distinct PCI device.
> (0000:0c:00.0 Goshen Ridge) instead of tunneling. I've compiled together some
> evidence towards this from my investigation in attached md file. 

Your Thunderbolt/USB4 host controller is using firmware connection manager
so we have quite little visibility what it is doing. However, I know that
it follows the same "rules" as the Linux software connection manager and
only enables the device xHCI if the link is not USB4. So if you are using
passive TB3/4/5 cables you should get USB4 link and also active TB4/5
cables.

You can verify this using tbdump from tbtools [1]

 # tbdump -r 0 -a 1 -vv -N 1 PORT_CS_18

Look at TCM bit. If it is set then the link is TB3 and you get the
integrated xHCI for that reason. Of it is not set then something is wrong
and we need to investigate.

(or -a 3 depending on which port you connected the device, tbadapters -r 0
shows the active adapters).

[1] https://github.com/intel/tbtools

> Also, if it's useful I tried a cold boot with connected dock with pci=realloc
> as a boot option after gathering these captures. The control died in the same
> way as initially shared. 

Better not to set any non-standard command line options. They typically do
more harm if you don't absolutely know what they are doing.

In your case if this is a PCIe add-in card then it still requires proper
BIOS support for resource allocation and power management. Otherwise it
will not work as expected.