On Fri, 25 Sep 2026 20:28:14 -0400, Ben wrote:
> Kernel Information:
> >   git remote -v
> > origin https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (fetch)
> > origin https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (push)
> > thunderbolt https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git/ (fetch)
> > thunderbolt https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git/ (push)
> >   git status
> > HEAD detached at thunderbolt/master
> > Changes not staged for commit:
> >  (use "git add <file>..." to update what will be committed)
> >  (use "git restore <file>..." to discard changes in working directory)
> > modified:   drivers/usb/host/xhci-mem.c
> > modified:   drivers/usb/host/xhci.c  
> 
> I've provided more snapshots. One with the quirks from console
> options, one without.

This looks right, but the debugfs dumps don't seem to have been taken
from the patched kernel. Not sure what are those slot_2xx directories,
but neither of them has the bogus IR0_ERSTBA_LOW value.

Was USB functional at all? The patch would break it. Maybe it wasn't
ideal, please try this revised patch which only touches the suspect
host controller. And don't use xhci_hcd.quirks=0x800000 anymore.

Please confirm that the string "beef cafe" appears in dmesg, this shows
that the patch is applied and it recognized the suspect controller.
Then check if there are any "AMD-Vi" errors logged, particularly at
addresses 0xbeef0000 and 0xcafe0000, and check this:

# grep ERSTBA_LOW /sys/kernel/debug/usb/xhci/0000\:0c\:00.0/reg-runtime
IR0_ERSTBA_LOW = 0xbeef0000
  
> usbmon.txt is the result of:
>   sudo cat /sys/kernel/debug/usb/usbmon/0u | tee usbmon.log
> 
> followed by:
>   echo 0000:0c:00.0 | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
>   sleep 2
>   echo 0000:0c:00.0 | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind

This confirms that USB core initializes the hub, detects connected
ports and tries to enable them without working Port Status Change
events. Hub interrupt endpoints only see submissions and unlinks.

I separately confirmed the same on my system. I completely patched
out the call to handle_port_status() and devices connected during
driver reload were still detected, only hotplug stopped working.

So it's not surprising that Enable Slot command is queued without
functional xHCI events.

Regards,
Michal