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

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

[Mika Westerberg]

Hi,

On Tue, Nov 03, 2026 at 10:18:28AM -0800, 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.
> 
> Observations:
>   - With only one display connected (either one), it does not happen.
>   - Booting with one display and hot-plugging the second after login did not
> trigger it in one test.
>   - With thunderbolt.dyndbg=+p, the Thunderbolt driver logs nothing in the
> window before the failure, so tunnel and bandwidth changes don't appear to be
> involved.

I agree, I checked the log you shared (although it missed some details)
tunnels look fine. One thing you can try is to run "sudo tbunnels -v" after
this happens so we can see if the USB3 tunnel is up.

You can get tbtunnels from [1].

[1] https://github.com/intel/tbtools

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]

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