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

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.


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

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.


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.



Bernd