APPLIED/Cmnt[Q]: [SRU][Q/R][PATCH 0/1] TBT call trace while connecting TBT4 monitor on TBT5 port

[Stefan Bader]

On 07/01/2026 06:57, AceLan Kao wrote:
> From: "Chia-Lin Kao (AceLan)" <acelan.kao at canonical.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/2137613
> 
> [Impact]
> 
> When connecting Thunderbolt devices (especially monitors like Dell
> U2725QE), users see alarming kernel backtraces in dmesg during device
> enumeration. While the devices eventually work after automatic
> reconnection, the call traces cause user concern and can trigger
> automated bug reporting tools.
> 
> Error log example:
> ```
> [ 36.031530] thunderbolt 0000:c7:00.6: PCIe Down path activation failed
> [ 36.031531] WARNING: drivers/thunderbolt/path.c:589 at 0x0, CPU#12: pool-/usr/libex/3145
> [ 36.031605] CPU: 12 UID: 0 PID: 3145 Comm: pool-/usr/libex Tainted: G D W 6.18.0+ #8
> [ 36.031610] RIP: 0010:tb_path_activate+0x126/0x530 [thunderbolt]
> [ 36.031637] Call Trace:
> [ 36.031638] <TASK>
> ...
> ```
> 
> The issue occurs when:
> - Type-C connections have transient electrical issues
> - During lane bonding transitions (single lane to dual lane)
> - The Thunderbolt port's control channel is temporarily unavailable
> 
> The devices typically recover automatically within a few seconds and work
> normally, but the kernel backtrace (tb_WARN) is generated unnecessarily
> for these expected transient conditions.
> 
> Affected hardware:
> - Dell U2725QE Thunderbolt monitor (USB4 device 8087:b26)
> - Other Thunderbolt/USB4 devices experiencing similar transient connection issues
> - AMD and Intel Thunderbolt controllers
> 
> [Fix]
> 
> Modify tb_path_activate() in drivers/thunderbolt/path.c to differentiate
> between expected transient failures and actual errors:
> 
> - For -ENOTCONN errors: Use tb_warn() to log the error without generating a kernel backtrace
> - For all other errors: Keep tb_WARN() to generate the full call trace for debugging
> 
> This approach aligns with the existing comment in drivers/thunderbolt/ctl.c
> which states that TB_CFG_ERROR_PORT_NOT_CONNECTED "can happen during
> surprise removal" and we should "not warn" about it.
> 
> The fix does not suppress the warning message itself - users and developers
> can still see the path activation failure in dmesg. It only removes the
> unnecessary kernel backtrace (stack dump, register dump, etc.) for this
> specific expected transient condition.
> 
> Patch: https://lore.kernel.org/lkml/20260102031905.27416-1-acelan.kao@canonical.com/T/#u
> ("thunderbolt: Suppress call trace for transient -ENOTCONN errors during
> path activation")
> 
> [Test Plan]
> 
> Hardware needed:
> - Dell U2725QE Thunderbolt monitor or similar Thunderbolt device that
>    exhibits transient connection issues
> - System with Thunderbolt 3/4 or USB4 controller
> 
> Test steps:
> ```bash
> # Clear dmesg
> sudo dmesg -C
> 
> # Connect Dell U2725QE or similar Thunderbolt device
> # Wait 10 seconds
> 
> # Check for call traces
> dmesg | grep -A 30 "path activation failed"
> ```
> 
> Without the patch: A full kernel backtrace appears with WARNING, RIP, Call
> Trace, register dump, etc.
> 
> With the patch: Only a simple warning message appears without the backtrace:
> ```
> thunderbolt 0000:c7:00.6: PCIe Down path activation failed (port not connected)
> ```
> 
> [Where problems could occur]
> 
> The patch modifies error reporting in the Thunderbolt path activation code,
> which could affect debugging and error handling:
> 
> 1. **Thunderbolt subsystem**: If there are genuine bugs that manifest as
> -ENOTCONN errors (not just transient issues), developers might miss
> important debugging information because the full backtrace won't be
> generated. This would make it harder to diagnose actual Thunderbolt
> controller bugs or firmware issues.
> 
> Chia-Lin Kao (AceLan) (1):
>    UBUNTU: SAUCE: thunderbolt: log path activation failures without WARN
>      backtraces
> 
>   drivers/thunderbolt/path.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)APPL
> 
> --
> 2.51.0
> 
> 
This is a bit of a mess now... The bug reference somehow slipped into 
patch 10/10 of "[SRU][Q][PATCH v2 00/10] No output on external monitor 
when connecting to dell dock" which got included in 2026.02.09. That 
means people get asked to verify without the patch being applied and it 
will be fun attempting to pull states and SWM verification requests 
back... (not)

Just now applying the correct patch for 2026.03.09...

Applied to questing:linux/master-next. Thanks.

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 52669 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260304/a095f97c/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260304/a095f97c/attachment-0001.sig>