Re: thunderbolt: PCIe tunnel creation fails for USB4 eGPU dock on Titan Ridge host

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.