APPLIED/Cmnt: [SRU][N][PATCH 0/2] TBT call trace while connecting TBT4 monitor on TBT5 port
Edoardo Canepa
edoardo.canepa at canonical.com
Fri Feb 6 12:18:00 UTC 2026
Applied to noble:linux/master-next. Thanks.
Patch #2 substituted with:
commit 062191adfde0b11b01656ea6db51a9385fa3d104 thunderbolt: Log path
activation failures without WARN backtraces
On 1/7/26 06:52, 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
>
> Mika Westerberg (1):
> thunderbolt: Show path name in debug log when path is deactivated
>
> drivers/thunderbolt/path.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --
> 2.51.0
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x20F88172E14F6784.asc
Type: application/pgp-keys
Size: 3167 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260206/1bd3dda1/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260206/1bd3dda1/attachment-0001.sig>
More information about the kernel-team
mailing list