[Bug 222091] Regression 7.1.10→7.2.x: poweroff hangs after Lenovo USB4 dock (40BF) connected during session; state persists after unplug

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=222091

--- Comment #2 from AlexTLDR (abadragan@gmail.com) ---
(In reply to Artem S. Tashkinov from comment #1)
> Could you please bisect?
> 
> Any LLM can guide you through it.

Follow-up: I found that the regression is resolved by the kernel
parameter thunderbolt.host_reset=0. With it, the machine powers off
cleanly even after the dock has been connected during the session.

Looking at what changed in drivers/thunderbolt between the last good
(7.1.x) and first bad (7.2.x) kernels, the suspect is commit
5f40cba7d4 "thunderbolt: Assert downstream port reset on shutdown",
merged for v7.2-rc1. That commit forces the host_reset path in the
PCI ->shutdown callback and asserts PORT_CS_19.DPR on each connected
downstream port before tearing down the router tree. This matches all
observations on this machine:

- the hang only occurs once the dock (router 17ef:118d) has been
  connected in the session, i.e. once a connected downstream port
  exists to assert the reset on
- the fault is latched (later unplugging does not help)
- host_reset=0 skips exactly this new shutdown-time reset sequence
  and the poweroff hang disappears
- "modprobe -r thunderbolt" deadlocks in the same teardown path

So the regression appears to be in the new downstream-port-reset
(SBTX-low) sequence: on this hardware (Insyde BIOS 1.07.03dTPCS,
Intel Core Ultra 200V, NHI 8086:a833) the assertion against the
Lenovo 40BF dock router never completes and the machine hangs at
firmware handoff.

Since that commit fixed a real issue elsewhere (60 s polling of a
dead link / warm reset on some platforms), a plain revert is probably
not the answer - perhaps the DPR assertion needs a timeout or a
quirk. Happy to test a patch or a scratch build with the revert to
confirm the identification.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.