Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #93134 > unrolled thread

Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94 dado <noantwort@tuta.io> - 2026-06-28 02:50 +0200
    Processed: Re: Bug#1140892: thunderbolt: Intel Goshen Ridge CL  state regression breaks dock tunneling since 6.12.94 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-06-28 21:10 +0200
    Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94 Salvatore Bonaccorso <carnil@debian.org> - 2026-06-28 21:10 +0200
      Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94 noantwort@tuta.io - 2026-06-29 01:10 +0200
        Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94 Salvatore Bonaccorso <carnil@debian.org> - 2026-06-29 07:00 +0200
    Processed: Re: Bug#1140892: thunderbolt: Intel Goshen Ridge CL  state regression breaks dock tunneling since 6.12.94 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-06-29 07:00 +0200
    Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94 Emmanuel Arias <eamanu@debian.org> - 2026-07-08 14:20 +0200
      Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94 noantwort@tuta.io - 2026-07-09 20:30 +0200
    Bug#1140892: marked as done (thunderbolt: Intel Goshen Ridge CL  state regression breaks dock tunneling since 6.12.94) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-22 19:10 +0200

#93134 — Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94

Source: linux
Version: 6.12.94-1
Severity: important
X-Debbugs-Cc: noantwort@tuta.io

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.


-- System Information:
Debian Release: 13.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.94+deb13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[toc] | [next] | [standalone]

#93143 — Processed: Re: Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94

Processing control commands:

> tags -1 + moreinfo upstream
Bug #1140892 [src:linux] thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94
Added tag(s) upstream and moreinfo.

-- 
1140892: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140892
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#93144

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: noantwort@tuta.io
> 
> 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

[toc] | [prev] | [next] | [standalone]

#93145

[Multipart message — attachments visible in raw view] — view raw

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 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: noantwort@tuta.io
>>
>> 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
>

[toc] | [prev] | [next] | [standalone]

#93147

Control: tags -1 - moreinfo

On Mon, Jun 29, 2026 at 12:51:27AM +0200, noantwort@tuta.io wrote:
> 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

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

[toc] | [prev] | [next] | [standalone]

#93146 — Processed: Re: Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94

Processing control commands:

> tags -1 - moreinfo
Bug #1140892 [src:linux] thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94
Removed tag(s) moreinfo.

-- 
1140892: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140892
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#93271

[Multipart message — attachments visible in raw view] — view raw

Hello Dado,

To follow the analysis and try get a solution for this, with the dock connected,
please run:

  fwupdmgr get-devices
  fwupdmgr refresh
  fwupdmgr get-updates

If updates are offered for the dock, you can run

  fwupdmgr update

Do you by chance have access to another unit of the same dock model? That would
help to tell whether this is a defect of your particular unit or something else.

Thank you very much!

-- 
cheers,
        Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eamanu@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#93297

[Multipart message — attachments visible in raw view] — view raw

Hi,

I did update a long time ago (immediately after I got the dock), at the time of the bug, the dock was already at the latest firmware.

Right now I am on kernel 6.12.95, there was no problem after updating from 6.12.94.
I also updated the system firmware BIOS from 0.1.19 to 0.1.20 also no problem.

Sorry, I don't have another unit of the same dock. I think the bug can be closed. I will monitor whether it happens again and try to find a pattern. I will also try to find some other dock with PCIe tunneling just for testing.

Thank you,
Dado


8 Jul 2026, 14:09 by eamanu@debian.org:

> Hello Dado,
>
> To follow the analysis and try get a solution for this, with the dock connected,
> please run:
>
>  fwupdmgr get-devices
>  fwupdmgr refresh
>  fwupdmgr get-updates
>
> If updates are offered for the dock, you can run
>
>  fwupdmgr update
>
> Do you by chance have access to another unit of the same dock model? That would
> help to tell whether this is a defect of your particular unit or something else.
>
> Thank you very much!
>
> -- 
> cheers,
>  Emmanuel Arias
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  eamanu@debian.org
>  ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
>  ⠈⠳⣄
>

[toc] | [prev] | [next] | [standalone]

#93425 — Bug#1140892: marked as done (thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Wed, 22 Jul 2026 18:03:26 +0100
with message-id <e46535aefd6f8f8ebd4d2cc2e824184361324a33.camel@debian.org>
and subject line Re: Bug#1140892: thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94
has caused the Debian Bug report #1140892,
regarding thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1140892: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140892
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web