On 3/3/25 02:46, Mika Westerberg wrote:
Like discussed, let's deal one issue at the time.
Understood, but when my machine keeps locking up after a resume from
suspend/hibernate under normal use-cases I really need(ed) to get to the
bottom of things, as it was beginning to interfere with my workflow.
OK, so first:
1) Hang/crash during resume when dock + NVMe is disconnected before resume.
For the first is this now solved if you revert
9d573d19547b3fae0c1d4e5fce52bdad3fda3664 ?
Yes, and thank you for that.
You can "isolate" this to PCIe side completely by doing the steps with the
commit but don't connect any monitors.
Yeah, that's how I'd started to verify that, as the DP tunnel crashing
issue was getting in the way of testing.
If this gets solved by the revert then that's one issue nailed, good.
After several cycles this appears to be the case.
Now I'd like to help you guys figure out what was causing the panics.
For the second issue, I'm not sure I know the steps but since you mention
reverting d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation
asynchronously"), it should trigger pretty much any time you plug in
monitor so we can follow different and hopefully simpler steps:
1. Boot the system up, nothing connected.
2. Connect TBT 4 dock to the system.
3. Connect monitor to the TBT 4 dock.
Expectation: Monitor shows the screen properly.
Actual result: Blank screen.
Actually, what was happening was connecting a monitor at any time worked
as expected. The issue was approximately most of the time after a resume
from suspend/hibernate, if I had an external (DP tunneled) monitor
connected, I'd get OOPSes in the line mentioned in my first E-mail,
which appeared from tracing to come from trying to write to a TB
tunnel(?) which no longer existed; my (totally wild) guess was that some
race condition between: resuming the machine and reenumerating the
tunnels, my monitors taking their time coming out of sleep, and
"something" happening with the async tunnel activation means it was
hitting an NPE somewhere.
Bottom line is I've done quite a bit of testing with these reverts and
have yet to get any resume from S/H failures since.
... and as with 9d573d19, I'd like to help fix this underlying issue, as
maybe there's something unique to my laptop's chipset(?) (as I have
different docks and monitors at home and when on the road but it happens
in both scenarios).
-Kenny
