Dear Maintainer,

Thunderbolt 4 dock stops working completely after upgrading from
6.12.90+deb13.1-amd64 to 6.12.94+deb13-amd64. The dock is detected
and authorized by bolt but all tunnel creation fails, making peripherals
and laptop charging unavailable. A similar issue has occurred on
previous kernel upgrades on this machine.

== Hardware ==

Machine:     Lenovo ThinkPad T16 Gen 4 (21QN001MSC)
CPU:         AMD Ryzen AI 7 PRO 350 w/ Radeon 860M
TB controller: Intel Thunderbolt 4 Goshen Ridge [8086:0b26] rev 03
               (PCI 61:00.0 / 62:00.0-04.0)
Dock:        Lenovo ThinkPad Thunderbolt 4 Smart Dock Gen 2 7500
             (vendor=0x108 device=0x2350)

== Regression range ==

Last working kernel: 6.12.90+deb13.1-amd64
First broken kernel: 6.12.94+deb13-amd64

== Symptoms ==

- Dock LED blinks white/orange
- Laptop does not charge via dock
- No peripherals (USB, display) detected
- bolt correctly authorizes the device (policy: iommu)
- Dock reconnect loop: detected -> tunnel failure -> disconnected -> repeat

== dmesg output (6.12.94, dock plugged in) ==

[  261.001240] thunderbolt 1-2: new device found, vendor=0x108 device=0x2350
[  261.001253] thunderbolt 1-2: Lenovo ThinkPad Thunderbolt 4 Smart Dock Gen 2 7500
[  262.127865] thunderbolt 0000:c6:00.6: 2: failed to enable CL states
[  262.129297] thunderbolt 0000:c6:00.6: 2: USB3 tunnel creation failed
[  262.130455] thunderbolt 0000:c6:00.6: 2:1: hop deactivation failed for hop 1, index 8
[  262.130463] thunderbolt 0000:c6:00.6: path activation failed
[  262.130573] WARNING: CPU: 0 PID: 4777 at drivers/thunderbolt/path.c:587 tb_path_activate+0x10e/0x4a0 [thunderbolt]
[  262.130789]  tb_tunnel_restart+0x9e/0x190 [thunderbolt]
[  262.130804]  tb_tunnel_pci+0x1ae/0x390 [thunderbolt]
[  262.130819]  authorized_store+0x27b/0x2c0 [thunderbolt]
[  262.130976] thunderbolt 0000:c6:00.6: 0:5 <-> 2:9 (PCI): activation failed
[  262.131168] thunderbolt 0000:c6:00.6: 2:9: PCIe tunnel activation failed, aborting
[  262.131794] thunderbolt 1-2: device disconnected

== Root cause ==

The regression is in CL (clock latency) state negotiation between the
thunderbolt driver and the Intel Goshen Ridge controller. Repeated failed
connection attempts also leave stale routing table entries in the dock
firmware, requiring a full dock power cycle to recover.

== Workaround ==

Adding thunderbolt.clx=0 to GRUB_CMDLINE_LINUX_DEFAULT disables CL state
negotiation and restores normal operation. A full dock power cycle
(laptop shutdown + dock unplugged from wall for 30s) is required once
to clear accumulated stale state.

Confirmed: /sys/module/thunderbolt/parameters/clx reads N with this
parameter set, and the dock functions correctly.

Control: tags -1 + moreinfo upstream

Since you reliably can reproduce the issue and regression, can you
please bisect the changes between 6.12.90 and 6.12.94 upstream to
identify the breaking commit. This will involve compiling and testing
a couple of kernels.

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.90
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.90 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem does not exist

    # test 6.12.94 to ensure this is "bad"
    git checkout v6.12.35
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem exists

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v6.12.90
    git bisect bad v6.12.94

In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, verify if problem exists

and if the problem is hit run:

    git bisect bad

and if the problem doesn't trigger run:

    git bisect good

. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.

Iterate until git announces to have identified the first bad commit.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.

Regards,
Salvatore

Sorry for the trouble, I was wrong.

I incorrectly diagnosed this as a kernel regression introduced in 6.12.94, problem is in the dock itself.

The "failed to enable CL states" / "failed to enable TMU" / "PCIe tunnel activation failed" messages were a SYMPTOM of the dock's internal tunnel/routing state being stuck after repeated failed
re-attach attempts, not the root cause. The actual fix was the cold power-cycle.
(An earlier workaround, thunderbolt.clx=0, appeared to help, but it was the power-cycle and not the kernel parameter that restored function. clx=0 is not required.)

The kernel was upgraded 6.12.90-2 -> 6.12.94-1 via a package update. A new kernel only takes effect on reboot, so the dock kept working until the next reboot. The trigger was the reboot after
the kernel install, not the kernel code.

The dock does not reliably re-attach across a warm reboot and needs a coldpower-cycle to reset.
Also, I reverted to the kernel 6.12.90 and then back to 6.12.94 and it keeps working in both directions.
(In normal day-to-day use this has occurred three times in a row following a kernel update, yet when I deliberately try to reproduce it, the dock works fine)

Sorry again

Dado
28 Jun 2026, 21:03 by carnil@debian.org:

Control: tags -1 - moreinfo

Thanks a lot for reporting back.

I'm leaning towards closing then this bugreport assuming it is solely
an issue with the Dock. But I will wait until having discussed it with
other members in the kernel team.

Regards,
Salvatore