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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3/3/25 03:21, Mika Westerberg wrote:

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.
...
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.

I will do this in a couple of days (got a few things to do first), but what actually happens is I get as OOPS and have to power-button-reset to recover, not even SysRq-B gets me out of it (I've since added "Panic on OOPS" with a 15-second timeout while I was trying to figure out this DP monitor issue).

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.

It'll have to be more pstore dumps, as resume doesn't (usually) complete with d6d458d42e1.

And apparently this became two issues as d6d458d42e1 was added to Linus' master somewhat recently, and after I'd started the issue of the NVMe OOPSes on resume, so I'd get two different crashes, depending on what was connected when I'd suspend, and what was connected when I'd resumed.

Once you'd discovered 9d5.., which I'd reverted that same day, it then isolated the second failure mode (which was the reason for those __tb_path_deactivate_hop()s in the dmesg/pstores I'd been sending, as I thought it was related to the original NVMe adaptor crashes, but helped me then find this current problematic commit).

... and as with 9d573d19

I don't think this is hardware issue, I see it too in my hardware

Sorry, wasn't clear- what I'd meant was "Just as with [the revert of] 9d573d19 I'd like to help figure out what's causing d6d458d42e1 to OOPS my machine on resume."

-Kenny

--
Kenneth R. Crudup / Sr. SW Engineer, Scott County Consulting, Orange County CA





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux