Re: Apple Studio Display (2026 , Thunderbolt 5) — DP tunnel torn down every few minutes on Intel TB4 host

Hi Bernd,

On Tue, Aug 04, 2026 at 04:57:05PM +0200, Bernd Behler wrote:
> Hi Mika,
> 
> Both things done. Short version: the MST lead does not hold, and I can now
> show why rather than just assert it.

Okay thanks (and thanks for the very informative reports).

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

Okay then, like you already suspect, this is not the firmware issue related
to the MST.

Since there is nothing the software is doing (well at least directly) to
cause this, I wonder if it could be related to some sort of power
management thing in the monitor itself? The second idea that comes to mind
is power supply but I guess you are using the stuff that came with the
monitor so it should provide the necessary power.

Based on your dump it also happens to both DP OUT adapters (11, 12) at the
same time.

Also, you connect the monitor with a real TB cable, right? I would think so
because the USB4 link comes up just fine.

You don't see any "usage" pattern there when this happens?

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

Thanks for checking!

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

This is not expected. What typically happens is that there is another
hotplug and the DP tunnels get re-established. This is what you may see
here but it's not visible in the log snippet you shared so I cannot
confirm. You should see in the log or trace that the tunnels get
re-established.