All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Phani Kumar <phanigudipally@gmail.com>
Cc: mathias.nyman@linux.intel.com, linux-usb@vger.kernel.org
Subject: 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
Date: Wed, 4 Nov 2026 13:10:48 +0100	[thread overview]
Message-ID: <20261104121048.GE176724@black.igk.intel.com> (raw)
In-Reply-To: <CAMcR36+hWzhS_Pytej3uoDvOU6160v5vtuWXSnyFb=zEoRFQJQ@mail.gmail.com>

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

       reply	other threads:[~2026-11-04 12:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMcR36+hWzhS_Pytej3uoDvOU6160v5vtuWXSnyFb=zEoRFQJQ@mail.gmail.com>
2026-11-04 12:10 ` Mika Westerberg [this message]
2026-11-10  9:08 ` 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
     [not found]   ` <CAMcR36LCr0RFrHsLFPaPziPS=1CMbEnO3GcDk=3Oe33S8uZFpw@mail.gmail.com>
2026-11-12 14:55     ` Mathias Nyman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261104121048.GE176724@black.igk.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=phanigudipally@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.