On Mon, Mar 03, 2025 at 03:02:30AM -0800, Kenneth Crudup wrote:
> > 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.
Let's not guess, let's try to figure out the root cause.
> 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.
Okay that's good.
Now you say that you don't reproduce the DP tunnel issue if you simply plug
in monitor so let's try to figure out reliable steps to repro so we can
investigate.
In theory it should trigger any time you plug in monitor since the paths
are the same but okay. Then let's try to limit this to single monitor (the
one you see this most reliably and let's stick with suspend since hibernate
is more complex).
So with 9d573d19547b3 only reverted, no other changes to the kernel and
"thunderbolt.dyndbg=+p" in the command line do following steps:
1. Boot the system up, nothing connected.
2. Connect TBT 4 dock to the system.
3. Connect monitor to the TBT 4 dock.
4. Suspend the system by closing lid.
5. Resume the system by openling lid.
Expectation: Monitor over Thunderbolt still shows picture.
Actual result: Screen is blank.
If these are not accurate, can you in the same format write down your steps
how it reproduces (try to keep it minimal). Then since now resume at least
completes you can provide full dmesg to me and I can try to figure out what
is wrong there.
> ... 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).
I don't think this is hardware issue, I see it too in my hardware so the
commit just somehow ends up in a deadlock and of course needs to be
investigated but for the time being we can use the workaround revert and
concentrate on the DP issue at hand.
