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