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

Hi,

On Fri, Aug 07, 2026 at 11:55:24AM +0200, David GUENAULT wrote:
> On Fri, Aug 07, 2026 at 06:37 +0300, Mika Westerberg wrote:
> > That's because Titan Ridge is using firmware based connection manager so
> > it's not the TB driver that creates the tunnels.
> >
> > Can you drop all the non-distro kernel command line options, except
> > "thunderbolt.dyndbg=+p" and provide full dmesg?
> 
> Thanks -- you are right, and my original analysis was wrong on that point.
> I had been enabling dyndbg after boot, so I never saw the init messages and
> wrongly concluded from the port dumps that the software CM was in use.
> 
> Rebooted with a clean command line as requested. Kernel is vanilla mainline
> v7.1.5 (build from kernel.ubuntu.com/mainline, no distro patches):
> 
>   BOOT_IMAGE=/boot/vmlinuz-7.1.5-070105-generic root=UUID=... ro quiet splash
>   thunderbolt.dyndbg=+p vt.handoff=7
> 
> Everything except thunderbolt.dyndbg=+p is generated by Ubuntu's GRUB.
> I also disabled the udev rules I had been using (they forced
> power/control=on on the thunderbolt and 8086:15e7/15e8/15e9 PCI devices),
> so this boot is entirely stock.
> 
> The firmware CM is indeed in use:
> 
>   [    1.673598] thunderbolt 0000:03:00.0: total paths: 12
>   [    1.673598] thunderbolt 0000:03:00.0: IOMMU DMA protection is enabled
>   [    1.673945] thunderbolt 0000:03:00.0: control channel created
>   [    1.673949] thunderbolt 0000:03:00.0: using firmware connection manager
>   [    1.673950] thunderbolt 0000:03:00.0: NHI initialized, starting thunderbolt
> 
> The dock is found and the link comes up bonded at 40 Gb/s, then:
> 
>   [    6.012100] thunderbolt 0000:03:00.0: PCIe tunnel creation failed
> 
> If I read icm.c correctly, that message is emitted by icm_*_approve_switch()
> when the firmware replies with ICM_FLAGS_ERROR, so the Titan Ridge firmware
> is refusing the tunnel rather than the driver failing to build it. Is that
> the right reading? If so, is there anything on the host side that can be
> inspected or adjusted, or is this purely an NVM/firmware limitation?

This could be a limitation in FW but TB5 devices should be compatible with
TB3 connection manager. 

> One setting that is NOT a kernel command line option and may matter:
> BIOS "Thunderbolt Security Level" is set to "Unique ID" (SL1), which shows
> up as security=user in sysfs. This is deliberate: with "No Security"
> (security=none) the device is auto-authorized, approve_switch is never
> called, no tunnel is ever attempted and nothing at all is logged -- the
> device just silently appears authorized but unusable. Switching to SL1 is
> what makes the firmware actually be asked for the tunnel.

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.

Then take full dmesg (and also output of 'sudo lspci -vv') and send to me.
The dmesg you shared was badly line wrapped so if you can please attach the
them instead (you can send them directly to me or put them somewhere I can
download).

Note if security is none bolt does not try to authorize the PCIe tunnel as
it does not need to so this is expected.