Public bug reported:
**Title**
linux-oem-7.0: shutdown/reboot hangs in nhi_pci_shutdown() after a
Thunderbolt dock with DisplayPort is plugged in (missing upstream fix
1fd1f67c94d3)
**Description**
After plugging in (and optionally unplugging) a Thunderbolt 4 dock, the
next shutdown or reboot hangs forever after "systemd-shutdown:
Rebooting" / "Powering off". The machine has to be powered off with the
power button.
This is a regression introduced in linux-oem-7.0 7.0.0-1010.10 by the backport
of
"thunderbolt: Wait for tb_domain_release() to complete when driver is removed"
(part of LP: #2160699).
That change makes the NHI remove/shutdown path wait for the domain reference
count to reach zero. A pre-existing domain reference leak in the DisplayPort
tunnel DPRX path then turns from a small memory leak into a permanent hang.
Upstream already fixed the leak:
- 1fd1f67c94d3 "thunderbolt: Fix domain reference leak when DPRX read is
canceled" (Cc: stable, in v7.3)
and two closely related fixes from the same series:
- 12f5d8b85a66 "thunderbolt: Make the DP tunnel activation callback mandatory"
- 419fa32fa5bc "thunderbolt: Don't access a DP tunnel after its DPRX read was
canceled"
Please backport these three commits to linux-oem-7.0.
**System**
- Ubuntu 26.04.1 LTS
- Kernel: 7.0.0-1015-oem #15-Ubuntu (linux-image-7.0.0-1015-oem 7.0.0-1015.15)
- Hardware: HP ZBook Ultra G1a 14 inch Mobile Workstation PC (AMD Ryzen AI MAX+
PRO 395), BIOS X89 Ver. 01.06.02
- Dock: Belkin Thunderbolt 4 5-in-1 Core Hub (Thunderbolt vendor 0x13, device
0x6e)
- The kernel is tainted (OE) by a locally rebuilt amdgpu.ko that only changes
the backlight brightness curve; the thunderbolt and thunderbolt_net modules
used for the reproduction are the unmodified packaged ones.
**Steps to reproduce**
1. Boot 7.0.0-1015-oem.
2. Plug in the dock (a display does not need to be connected), wait a few
seconds, unplug it.
3. Reboot or power off.
Expected: the system reboots / powers off.
Actual: it hangs after the "Rebooting." message. Reproduced with the unmodified
packaged thunderbolt.ko (and thunderbolt_net.ko) of 7.0.0-1015.15; it hung on
the first attempt. Earlier, with a module that differs only by an unrelated
XDomain change in xdomain.c, 4 of 4 attempts hung. Shutdown without plugging
the dock is normal.
**Analysis**
A kdump captured with hung_task_panic shows PID 1 blocked in the
shutdown path:
```
INFO: task systemd-shutdow:1 blocked for more than 30 seconds.
task:systemd-shutdow state:D stack:0 pid:1
wait_for_completion+0x81/0x140
nhi_pci_shutdown+0x5d/0x80 [thunderbolt]
pci_device_shutdown+0x37/0x90
device_shutdown+0x148/0x210
kernel_restart+0x3a/0x70
__do_sys_reboot+0x156/0x250
```
The wait is `wait_for_completion(&nhi->domain_released)` in
nhi_pci_do_remove() (drivers/thunderbolt/pci.c:500 in 7.0.0-1015), which
completes only from tb_domain_release().
With thunderbolt dynamic debug enabled, right after plug-in the same DP
tunnel is created twice within 0.5 s. The first one is torn down ("DP
OUT resource unavailable: adapter unplug") before its DPRX capabilities
read finishes, and its activation callback never runs.
tb_tunnel_one_dp() hands tb_domain_get(tb) to that callback, and only
the callback drops it; tb_dp_dprx_stop() cancels the delayed work and
drops only the tunnel reference. So each such event leaks one domain
reference, and the domain is never released at shutdown. This dock's DP
OUT adapter flaps once on every plug-in, so the leak happens on every
connection.
Kernel log from the reproduction on the stock module
(`thunderbolt.dyndbg=+p`, excerpt). The first tunnel is torn down 0.26 s
after activation with no DPRX completion; the second one completes
normally:
```
[30.948654] thunderbolt 1-2: new device found, vendor=0x13 device=0x6e
[32.603844] thunderbolt 0000:c5:00.6: 0:6 <-> 2:13 (DP): activating
[32.865164] thunderbolt 0000:c5:00.6: 2:13: DP OUT resource unavailable:
adapter unplug
[32.865219] thunderbolt 0000:c5:00.6: 0:6 <-> 2:13 (DP): deactivating
[33.079726] thunderbolt 0000:c5:00.6: 0:6 <-> 2:13 (DP): activating
[33.105031] thunderbolt 0000:c5:00.6: 0:6 <-> 2:13 (DP): DPRX read timeout
[33.155048] thunderbolt 0000:c5:00.6: 0:6 <-> 2:13 (DP): DPRX capabilities read
completed
[42.888296] thunderbolt 0000:c5:00.6: 0:6 <-> 2:13 (DP): deactivating
[42.888844] thunderbolt 1-2: device disconnected
```
This matches the commit message of upstream 1fd1f67c94d3, which also
notes that since "Wait for tb_domain_release() to complete when driver
is removed" the leak blocks forever instead of only leaking memory.
**Test result with the fix**
The three upstream commits apply to the 7.0.0-1015 thunderbolt sources with
only line offsets (GNU patch, fuzz ≤ 2).
With these three commits applied to the packaged sources (the test module
additionally carries an unrelated XDomain protocol-handler change in
xdomain.c), plugging and unplugging the same dock followed by a reboot
completed normally (dock connected 03:42:54, disconnected 03:43:18, clean
reboot at 03:50:41; no hung task, no WARNING).
A minimal local patch that only drops the domain reference in tb_dp_dprx_stop()
when the work is canceled fixed the hang (dock plug/unplug followed by reboot
completed normally); the upstream commits are preferred because they also fix
the related race.
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: linux-image-7.0.0-1015-oem 7.0.0-1015.15
ProcVersionSignature: Ubuntu 7.0.0-1015.15-oem 7.0.14
Uname: Linux 7.0.0-1015-oem x86_64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Sun Oct 25 04:16:08 2026
InstallationDate: Installed on 2026-01-17 (280 days ago)
InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64
(20250805.1)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: linux-signed-oem-7.0
UpgradeStatus: Upgraded to resolute on 2026-10-24 (0 days ago)
** Affects: linux-signed-oem-7.0 (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug resolute wayland-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172135
Title:
linux-oem-7.0: shutdown/reboot hangs in nhi_pci_shutdown() after a
Thunderbolt dock with DisplayPort is plugged in (missing upstream fix
1fd1f67c94d3)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-oem-7.0/+bug/2172135/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
