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

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

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

On Thu, 24 Sep 2026 18:18:53 -0400, Ben wrote:
> >I noticed that both event and command rings DMA addresses are above
> >32 bit. Maybe dmesg log with usb core and xhci dynamic debug enabled
> >could show something. Can you add the following to the kernel cmd
> >line:  
> 
> Unfortunately, did not fix the issue.

Broken 64 bit support usually shows as IOMMU faults logged in dmesg,
because the chip tries to access different addresses than intended.
Here, it looks like this chip doesn't attempt DMA at all.

USBSTS.HSE is supposed to be set by the chip if its DMA transactions
are failing, but it's clear. Only "Port Change Detect" is set.

I suspect we could write junk into CRCR and ERSTBA and nothing would
change. Maybe worth trying, see patch attached.

Are you using some Thunderbolt adapter in a motherboard not officially
supported by this adapter? I recall reading about such configurations
that they may need various tweaks to work.

But Windows works, right?

> > Odd thing is that event ring is completely empty.
> > There's usually a port change event when host detects a device,
> > this event triggers hub driver to start the usb device enumeration
> > process, queuing the 'enable slot' command as one of the first
> > steps.
> >
> > Either xHC isn't really running, or fails to write to the event
> > ring.

I think usbcore scans hubs using control transfers without waiting for
any change events. Here control transfers are emulated by xhci-hub.c
and turned into MMIO accesses. This, if confirmed, would indicate that
the HC is somewhat functional and responsive to MMIO, but doesn't DMA.

It can be confirmed by watching usbmon0 and then:

echo 0000:0c:00.0 >/sys/bus/pci/drivers/xhci_hcd/unbind
echo 0000:0c:00.0 >/sys/bus/pci/drivers/xhci_hcd/bind

Regards,
Michal

[-- Attachment #2: xhci-bogus-dma.patch --]
[-- Type: text/x-patch, Size: 1086 bytes --]

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 83ed26c4f9e4..8d0b42afe911 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2349,7 +2349,7 @@ void xhci_add_interrupter(struct xhci_hcd *xhci, unsigned int intr_num)
 
 	erst_base = xhci_read_64(xhci, &ir->ir_set->erst_base);
 	erst_base &= ~ERST_BASE_ADDRESS_MASK;
-	erst_base |= ir->erst.erst_dma_addr & ERST_BASE_ADDRESS_MASK;
+	erst_base |= 0xbeef0000;
 	if (xhci->quirks & XHCI_WRITE_64_HI_LO)
 		hi_lo_writeq(erst_base, &ir->ir_set->erst_base);
 	else
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e5c8b3a945a6..803cbadae9c5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -497,7 +497,7 @@ static void xhci_set_cmd_ring_deq(struct xhci_hcd *xhci)
 
 	crcr = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
 	crcr &= ~(CMD_RING_PTR_MASK | CMD_RING_CYCLE);
-	crcr |= deq_dma;
+	crcr |= 0xcafe0000;
 	crcr |= xhci->cmd_ring->cycle_state;
 
 	xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Setting command ring address to 0x%llx", crcr);