Re: [WARNING: UNSCANNABLE EXTRACTION FAILED]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/24/26 06:02, Ben wrote:
> Hello,
> 
>> 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.
> 
> I have had a usb drive plugged into the dock just for quickly checking
> whether the usb ports on the dock are working properly each boot via
> lsusb. I believe that was the case during the boot that I shared.
> 
>> 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.
> 
> I was truly having a hard time figuring out how to get this
> information on Windows and it really was not cooperating when I booted
> it up.
> If it's still useful, the next time around (or within the next couple
> days when I can find some time) I can confirm this with certainty.
> 
>> 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):
> 
> I've attached logs that should contain the relevant information around
> the time of this event:
>      command-ring  msi-irqs.txt    pci-irq.txt      proc-interrupts.txt
>   reg-op       uptime.txt
>      event-ring    pci-enable.txt  power-state.txt  reg-cap
>   reg-runtime
> 
>> [   24.975645] xhci_hcd 0000:0c:00.0: Abort failed to stop command ring: -110
> 
> I am providing these and I will hold onto additional ones from 2.48
> seconds into the boot.
>      24.57 /run/xhci-initrd/slot_200
>      24.68 /run/xhci-initrd/slot_201
>      24.79 /run/xhci-initrd/slot_202
>      24.90 /run/xhci-initrd/slot_203
>      25.01 /run/xhci-initrd/slot_204
>      25.12 /run/xhci-initrd/slot_205
> 

Thanks for the logs.

Registers show xHC and the command ring are running, but it still didn't process the
'enable slot' command. There are no command completion events on the event ring.
No interrupts either, but that is expected as there are no events.

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 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:

xhci_hcd.dyndbg=+p usbcore.dyndbg=+p

Could also be worth testing with with 32bit DMA mask:

xhci_hcd.quirks=0x800000


Details from slot_200 logs;
reg-op
USBCMD = 0x00000005     xHC is Running with interrupts enabled,
USBSTS = 0x00000010     port change detect active, EINT==0 so no unhandled interrupt pending.
CRCR = 0x00000008       command ring is running

reg-runtime
MFINDEX = 0x00003252
IR0_IMAN = 0x00000002      primary interrupter enabled
IR0_ERDP_LOW = 0x026d3000  event ring dma address has both high and low 32 bit values
IR0_ERDP_HIGH = 0x00000001

command-ring/trbs
  0 0x00000001026d1000: Enable Slot Command: flags C
  0 0x00000001026d1010: type 'UNKNOWN' -> raw 00000000 00000000 00000000 00000000

event-ring/trbs
  0 0x00000001026d3000: type 'UNKNOWN' -> raw 00000000 00000000 00000000 00000000
  0 0x00000001026d3010: type 'UNKNOWN' -> raw 00000000 00000000 00000000 00000000

Event ring is empty, command ring shows the Enable Slot command that times out.

Thanks
Mathias