Re: xhci_hcd 0000:00:0d.0 (Panther Lake, 8086:e431): “Unknown event condition 199”, then HC died, with a TB4 dock and two displays

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 11/3/26 20:18, Phani Kumar wrote:
> Hi,
> 
> On a Framework Laptop 13 Pro (Panther Lake), the Type-C Subsystem xHCI
> controller (0000:00:0d.0, 8086:e431) reports a vendor-defined completion
> code 199 and then stops responding, taking down every USB 3 device behind a
> Thunderbolt 4 dock. It is triggered by Ethernet traffic through the dock.
> With two displays connected to the dock at boot it happens reliably within
> 1 to 4 minutes; without displays it happens intermittently.
> 
> Hardware:
>    Laptop:   Framework Laptop 13 Pro (Intel Core Ultra Series 3)
>    CPU:      Intel Core Ultra X7 358H, microcode 0x11a
>    BIOS:     03.02 (2026-05-26), ME firmware 21.0.6.1503
>    xHCI:     00:0d.0 Intel Core Ultra (Series 3) Type-C Subsystem xHCI
> [8086:e431] (rev 01)
>    TB host:  Intel Gen16 USB4 host router (8087:a000)
>    Dock:     Razer Thunderbolt 4 Dock Chroma (TB vendor 0x127, device 0x8),
> NVM 30.0
>    Ethernet: RTL8153 (0bda:8153) inside the dock, in-tree r8152 driver
>    Displays: two 2560x1440@60 on the dock's downstream TB4 ports
>              (one USB-C to DisplayPort, one USB-C to HDMI adapter)
> 
> Kernel: 7.3.1 (Ubuntu mainline build 7.3.1-070301-generic)
> 
> Reproduction:
>    1. Boot with the dock and both displays connected.
>    2. Generate network traffic over the dock's Ethernet (e.g. open a
> browser).
>    3. Within about 1 minute the xHCI controller dies, and every USB 3 device
> behind the dock disconnects.
> 
> Log:
>    xhci_hcd 0000:00:0d.0: ERROR Unknown event condition 199 for slot 5 ep 3
> , HC probably busted
>    r8152 2-3.4.5:1.0 eth0: NETDEV WATCHDOG: CPU: 11: transmit queue 0 timed
> out 5665 ms
>    r8152 2-3.4.5:1.0 eth0: Tx timeout
>    r8152 2-3.4.5:1.0 eth0: Tx status -2
>    r8152-cfgselector 2-3.4.5: reset SuperSpeed USB device number 6 using
> xhci_hcd
>    xhci_hcd 0000:00:0d.0: ERROR Unknown event condition 199 for slot 5 ep 3
> , HC probably busted
>    r8152 2-3.4.5:1.0 eth0: Stop submitting intr, status -71
>    xhci_hcd 0000:00:0d.0: xHCI host not responding to stop endpoint command
>    xhci_hcd 0000:00:0d.0: xHCI host controller not responding, assume dead
>    xhci_hcd 0000:00:0d.0: HC died; cleaning up
>    usb 2-3: USB disconnect, device number 3
> 
> Full kernel log attached.
> 

Could you take both xhci traces, and log with xhci and usb core dynamic debug enabled?

Looks like the endpoint or its contexts may be in some odd state
(vendor event for specific endpoint, and failure to stop endpoint)

mount -t debugfs none /sys/kernel/debug
echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
echo 1 > /sys/kernel/debug/tracing/tracing_on
< Reproduce issue >
Send output of dmesg
Send content of /sys/kernel/debug/tracing/trace

xHC may also refuse to add an endpoints if it doesn't have the bandwidth to handle it.

What do files under /sys/kernel/debug/usb/xhci/0000:00:0d.0/port_bandwidth'
show right after starting network traffic?

Thanks
Mathias