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 [email protected]: > Control: tags -1 + moreinfo upstream > > On Sun, Jun 28, 2026 at 02:45:36AM +0200, dado wrote: > >> Source: linux >> Version: 6.12.94-1 >> Severity: important >> X-Debbugs-Cc: [email protected] >> >> 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 >> > > 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 >
