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

Hi,

On Tue, Aug 04, 2026 at 10:01:32AM +0200, Bernd Behler wrote:
> Hi Mika,
> 
> Traces attached, two matched trace/dmesg pairs, each captured with
> drm.debug=0x104 plus "module thunderbolt +p", tbtrace enabled before and
> dumped after the event:
> 
>   trace-tc3-domain1.out.xz / dmesg-tc3-domain1.txt.xz   controller 00:0d.3
>   trace-tc1-domain0.out.xz / dmesg-tc1-domain0.txt.xz   controller 00:0d.2
> 
> Larger captures exist (up to 19M, several events each); say the word and I
> will put them somewhere downloadable.

Thanks! I think I need the full ones because these are just missing what
happened right before the DP OUT unplug packet arrived. If this is the MST
issue then the graphics driver did AUX read to certain MST range registers
that immediately triggered the DP OUT unplug.

I only need for one controller, no need for both.

> > Do you have full dmesg with the debugging enabled available somewhere?
> > Can you also repro this so that you enable tracing of the TB driver and
> > provide the output (alongside with the full dmesg so we can compare)
> 
> Attached, as above. Both pairs are from the same display on the two
> different Thunderbolt controllers, and the signature is identical apart
> from the PHY:
> 
>   00:0d.3, domain 1:  [ENCODER:521:DDI TC3/PHY TC3] - long
>   00:0d.2, domain 0:  [ENCODER:540:DDI TC1/PHY TC1] - long
> 
> > It should tear down the tunnel at that point.
> 
> Understood, thanks.
> 
> > Those happen until GFX reads the capabilites through the DP tunnel - its
> > normal
> 
> Good, I will stop treating DPRX read timeout as a symptom.
> 
> 
> Both displays attached at once
> ------------------------------
> 
> Since my report I ran the two models simultaneously, one on each
> controller, in the same compositor session:
> 
>   DP-3  Studio Display 2026 (NVM 64.81)   domain 0
>   DP-1  Studio Display 2022 (NVM 67.0)    domain 1
> 
>   Connector DP-3 disconnected    8
>   Connector DP-3 connected       8
>   Connector DP-1 disconnected    1
>   Connector DP-1 connected       2
> 
> The 2022 unit has never blanked in use, here or at any other time. Its
> single connector event in the log above is from cable handling, not a
> fault.
> 
> This is the same-host, same-kernel, same-moment version of the comparison
> in my original report.
> 
> 
> Newly ruled out since 2026-08-01
> --------------------------------
> 
> - Host firmware, completely. BIOS CRARL579.0023 (2025-03) ->
>   CRARL579.0032 (2026-07-28). The flash displays "Updating Intel
>   Thunderbolt Retimer FW"; retimer NVM goes 24.82 -> 26.85. That capsule
>   also carries iTBT 16.2, IOM 30.001e.0.0, SPHY 18.1.1.7053,
>   NPHY 18.1.0.7015, new PMC and EC. First failure 2.5 minutes after the
>   reboot, signature unchanged.
> 
> - Kernel version. Identical failure on 6.18.39 LTS and on 7.1.4. Two
>   branches roughly a year apart, so not a recent regression.
> 
> - Disabling Thunderbolt in the BIOS does not give a DP alt mode fallback
>   to compare against: the Type-C port disappears entirely, no video and no
>   USB, for either display. So I could not test this display without
>   tunneling.
> 
> 
> A TB5 sink on a TB4 host is not the issue as such
> -------------------------------------------------
> 
> The 2026 display runs without fault on a Mac mini M2 Pro, which is
> Thunderbolt 4, not 5. Combined with the 2022 unit tunneling fine on this
> Intel host, the failure needs both this sink and this host stack.
> 
> 
> > We also used to have similar issue, related to MST register access that
> > triggered DP OUT unplug but I think that's already worked around in the
> > graphics side for Meteor Lake.
> 
> This is the lead I would most like to follow. This host is Arrow Lake-H
> (Core Ultra 5 225H, 8086:7d51). Is that workaround gated on Meteor Lake?
> If it is, everything above fits: a host-side access pattern this sink does
> not tolerate, absent on macOS, handled on MTL but not on ARL.

I don't remember but Imre who is CC'd (but may be on vacation, I'll ping
him internally just in case) should be able to tell. I think it was applied
up to Panther Lake or so. That can be confirmed if you disable MST from
i915 (there is a module parameter that can be used to disable it. Let me
know if you don't find it and I will look it up).

> If it is a different mechanism, what would you need from me to decide
> whether a per-device quirk is justified?
> 
> 
> I may only have this display on hand for a few more days. If you or Imre
> want anything run on it — different tbtrace options, more debugging, a
> patch — please say so soon and I will do it while I still can.

OK.

> Unrelated oops in the same setup
> --------------------------------
> 
> Separate issue, flagging it here rather than opening a thread unless you
> prefer that. Pulling the display's mains lead while the Thunderbolt cable
> was still attached killed the machine on the first attempt, kernel 7.1.4:
> 
>   Oops: general protection fault, kernel NULL pointer dereference 0x0
>   RIP: 0010:strlen+0x4/0x30            (RDI = 0)
>   Workqueue: events ucsi_handle_connector_change [typec_ucsi]
>     kernfs_remove_by_name_ns
>     typec_unregister_partner     [typec]
>     ucsi_unregister_partner      [typec_ucsi]
>     ucsi_handle_connector_change [typec_ucsi]
> 
> Looks like a partner being unregistered with a NULL name during a
> connector-change storm. The worker dies in the global events queue and
> userspace hangs behind it. Full dmesg available on request.

Okay I suggest to report that separately.