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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Tue, Mar 04, 2025 at 09:29:49AM -0800, Kenneth Crudup wrote:
> 
> On 3/4/25 05:51, Mika Westerberg wrote:
> 
> > > > It only happens if you have TBT dock and the NVMe connected and you
> > > > disconnect them while the system is suspended. I suggest trying that a
> > > > couple times and see if that happens. For me it
> > > > happened pretty much on first suspend cycle.
> 
> So I've tried it twice again today-
> 
> 1 - CalDigit dock, NVMe adaptor. Put it to sleep, disconnected everything,
> even waited a while (call me crazy, but I swear how long the system is
> suspended seems to make a difference). Opened the lid, and it came right up.
> 
> 2 - CalDigit dock, NVMe adaptor. Hibernated, drove to clients' offices.
> Resumed, came up OK.
> 
> Now I'm curious what difference the "4. Authorize both PCIe tunnels, verify
> devices are there." makes to your system, as I have "boltd" running and that
> handles it for me.

It should not matter the underlying mechanism is the same. boltd is fine
here.

Can you try the more "synthetic" way if that makes any difference? E.g do
exactly following steps. Do not connect any monitors to keep DP out of
this.

Also do this first without the latest patch from Lukas so you can see that
the issue actually triggers. Then apply the patch, just that patch nothing
else and try again.

1. Boot the system up, nothing connected.
2. Plug in TBT 4 dock to the host.
3. Plug in TBT NVMe to the TBT 4 dock.
4. Verify that the devices are there (lspci)
5. Enter s2idle:

  # rtcwake -s 30 -mmem

6. Once the system suspends, unplug the device chain.
7. Wait for the system to wake up (it wakes up automatically in 30s).

Repeat steps 2. - 7. several times in a row (say 10).