Re: So, I had to revert d6d458d42e1 ("Handle DisplayPort tunnel activation asynchronously") too, to stop my resume crashes

[Kenneth Crudup <kenny@panix.com>]

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