From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: David GUENAULT <david.guenault@gmail.com>
Cc: Andreas Noever <andreas.noever@gmail.com>,
Mika Westerberg <westeri@kernel.org>,
Yehezkel Bernat <YehezkelShB@gmail.com>,
linux-usb@vger.kernel.org
Subject: Re: thunderbolt: PCIe tunnel creation fails for USB4 eGPU dock on Titan Ridge host
Date: Fri, 7 Aug 2026 13:35:01 +0200 [thread overview]
Message-ID: <20260807113501.GP235112@black.igk.intel.com> (raw)
In-Reply-To: <20260807112925.GN235112@black.igk.intel.com>
On Fri, Aug 07, 2026 at 01:29:25PM +0200, Mika Westerberg wrote:
> On Fri, Aug 07, 2026 at 01:01:22PM +0200, David GUENAULT wrote:
> > On Fri, Aug 07, 2026, Mika Westerberg wrote:
> > > So with IOMMU enabled SL1 is redundant and it may actually end up stepping
> > > a non validated path because these systems ship with IOMMU support so the
> > > CM firmware is by default "none".
> > >
> > > Can you put the BIOS settings back to the defaults and then repro but
> > > instead of booting with the device connected do this:
> > >
> > > 1. Boot the system up, nothing connected.
> > > 2. Once up, plug in the TB5 dock.
> >
> > Done. BIOS restored to factory defaults (only change kept afterwards:
> > Secure Boot disabled, because the mainline kernel build I am testing is
> > unsigned). Security level is back to the default:
> >
> > /sys/bus/thunderbolt/devices/domain0/security = none
> > /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection = 1
> >
> > Kernel is still vanilla mainline v7.1.5, command line unchanged apart from
> > the debug flag:
> >
> > BOOT_IMAGE=/boot/vmlinuz-7.1.5-070105-generic root=UUID=... ro quiet splash
> > thunderbolt.dyndbg=+p vt.handoff=7
> >
> > The udev rules I mentioned earlier are still disabled, so this is stock.
> >
> > Booted with nothing connected, then plugged the dock in at t=60s. The
> > firmware CM is used, as expected:
> >
> > [ 1.680488] thunderbolt 0000:03:00.0: using firmware connection manager
> >
> > and on hotplug:
> >
> > [ 60.228058] thunderbolt 0-1: new device found, vendor=0x41f device=0xd002
> > [ 60.228061] thunderbolt 0-1: Micro Computer (HK) Tech. Ltd. TBGAA
> > [ 60.228236] thunderbolt 0-1: device disconnected
> >
> > So the router is announced and then dropped 178 microseconds later. This
> > happens exactly once -- there is no reconnect loop. As you predicted, there
> > is no "PCIe tunnel creation failed" this time, since approve_switch is never
> > called at security=none.
> >
> > Nothing appears behind the Thunderbolt downstream port afterwards:
> > 02:01.0 stays at PresDet-, no device on bus 04, no GPU in lspci. The dock's
> > USB and Ethernet functions do not show up either.
> >
> > For reference, when the link does stay up (which happened in earlier tests),
> > the lane adapter error counters are all zero and the link reports
> > 40 Gb/s = 2 lanes * 20 Gb/s in both directions, so this does not look like a
> > signal integrity problem to me.
> >
> > Attached:
> > dmesg-factory-default.txt full dmesg (1330 lines)
> > lspci-vv-factory-default.txt full 'sudo lspci -vv' (1190 lines)
> >
> > Attaching them as files this time, sorry about the line wrapping in my
> > previous mail.
> >
> > Let me know if you want any other capture -- I can rebuild the kernel with
> > extra tracing if that helps.
>
> Thanks!
>
> There is pretty much no PCIe hotplug from your logs and the lspci shows the
> same as you also noticed. One thing that stands out:
>
> [ 1.745588] thunderbolt 0000:03:00.0: 0: NVM version 42.0
>
> I looked our latest NVM for TR and the version is 69.4, if I read right it
> also supports "SP" == Single Port == 2C version that you have. Now the
> release notes mention exactly issues with devices after Goshen Ridge (first
> TB4 dock) so that might actually apply in your case too because you have
> TB5 dock which is exactly the one after GR. There are certain bits that the
> CM needs to set for the tunneling to work in USB4 routers.
>
> I wonder if you have checked if there is firmware upgrade available for
> that? It should be available through fwupd but some OEMs don't do that
> (Dell and Lenovo at least do).
>
> I have TB5 dock here and TB3 system so I will try on my end if I can see
> similar behaviour.
Okay I took my laptop (TB3) and connected TB5 dock and I can see exactly
the same issue as yours. It definitely should work in TB3 compatible mode
but apparently not. Let me ask around.
prev parent reply other threads:[~2026-08-07 11:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 21:48 thunderbolt: PCIe tunnel creation fails for USB4 eGPU dock on Titan Ridge host David GUENAULT
2026-08-07 4:37 ` Mika Westerberg
2026-08-07 9:55 ` David GUENAULT
2026-08-07 10:18 ` Mika Westerberg
2026-08-07 11:01 ` David GUENAULT
2026-08-07 11:29 ` Mika Westerberg
2026-08-07 11:35 ` Mika Westerberg [this message]
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=20260807113501.GP235112@black.igk.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=david.guenault@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=westeri@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox