Hi Mika, Both things done. Short version: the MST lead does not hold, and I can now show why rather than just assert it.
Trace with nothing before the unplug
------------------------------------
Attached: trace-unplug-fast.out.xz, 2961 lines, controller 00:0d.2 only.
This one is captured differently. Instead of dumping by hand after noticing
the blank screen, I hooked the dump to the kernel message itself, so it runs
about one second after the event rather than minutes later. I also raised the
ftrace ring buffer to 224M so nothing can be evicted.
Timeline for that capture:
16:35:43 tbtrace clear + enable, buffer empty
16:41:18 1:11 DP OUT resource unavailable: adapter unplug
16:41:19 dump
Between arming and the event, 5 minutes 35 seconds, the buffer recorded
exactly zero packets. The first entry in the trace is the display's own
packet:
[74467.055264] tb_event Hot Plug Event Packet Domain 0 Route 1 Adapter 11
[00:05] 0xb Adapter Num
[31:31] 0x1 UPG
[74467.055287] tb_tx Notification Packet -> HP_ACK
The whole trace spans 22 ms. The host's first action is the acknowledgement.
The graphics side matches. Between 16:36:00 and the unplug at 16:41:18 there
is not a single AUX or DPCD access on either of that display's ports
(USBC1/USBC2) in dmesg with drm.debug=0x104. The last one before that was a
routine 0x00202 link status read four minutes earlier.
So there is no host-initiated access preceding the teardown at all, on either
the AUX channel or the Thunderbolt control channel. If an MST register read
were the trigger, it would have to appear here, and it does not.
MST disabled
------------
Tried it anyway, since you offered it as the way to confirm:
/proc/cmdline i915.enable_dp_mst=0
/sys/module/i915/parameters/enable_dp_mst N
No change. Two teardowns in the first six minutes after that boot, same
signature. For comparison, the run before it had four in twelve minutes.
Second attachment, trace-unplug-mstoff.out.xz, is one of those events with
MST off. Note it was dumped about five seconds after the event rather than
one, so it carries the re-detection traffic as well; the signature at the top
is the same.
> I think it was applied up to Panther Lake or so.
Then it should be active on this host, and the failure survives it either
way. Combined with the empty trace above I would treat the MST path as ruled
out unless Imre sees something I am missing.
One observation I cannot place
------------------------------
After a teardown, tbtunnels still lists both DP tunnels as established, with
bandwidth allocated:
Route 0 Adapter 5 <-> Route 1 Adapter 11: DisplayPort 0/25920 Mb/s
Route 0 Adapter 6 <-> Route 1 Adapter 12: DisplayPort 0/8640 Mb/s
while the DRM connector is down and the screen is blank. Whether that is
expected bookkeeping or a real mismatch I cannot judge.
> Okay I suggest to report that separately.
Will do, separate thread for the ucsi_unregister_partner oops.
Larger traces from earlier runs are still available, but they all have the
problem you pointed out: dumped too late, so they begin at the unplug packet
with the preceding traffic already evicted. The attached one does not, which
is why it is the only one I am sending.
Bernd
trace-unplug-fast.out.xz
Description: application/xz
trace-unplug-mstoff.out.xz
Description: application/xz
