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

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

[Bernd Behler]

Summary
-------

An Apple Studio Display (2026 model, Thunderbolt 5) connected to an Intel
Arrow Lake-H host with integrated Thunderbolt 4 loses its DisplayPort
tunnel every 2-5 minutes under normal desktop use. The screen goes black
for ~2 s, occasionally for several minutes. The Thunderbolt link itself,
the tunnelled USB3 and the tunnelled PCIe stay up throughout -- only the
DP tunnels are torn down and re-established.

The previous Studio Display model (2022, Thunderbolt 3) on the same host,
same port, same cable, same kernel does not show the problem.

Hardware
--------

Host:        Intel NUC 15 Pro "Cyber Canyon" (NUC15CRKU5), Core Ultra 5 225H
Host TB:     integrated, 8086:7ec2 / 8086:7ec3, host router generation 4
GPU:         Intel Arc 130T/140T (8086:7d51), i915
Kernel:      7.1.4-arch1-1 (Arch Linux)
Compositor:  Hyprland / aquamarine (Wayland, atomic KMS)

Failing display -- Apple Studio Display 2026
- EDID: manufacturer APP, model 44614, made week 1 of 2026
- TB device 0x8025, generation 4, 20.0 Gb/s x 2 lanes, NVM 64.81
- contains an Intel JHL9480 (Barlow Ridge, TB5) -- appears as
  8086:5786 PCIe switch behind the tunnel
- firmware updated via macOS immediately before these traces; no change

Working reference -- Apple Studio Display 2022
- EDID: manufacturer APP, model 44602, made week 7 of 2022
- TB device 0x801f, generation 3, NVM 67.0

Symptom
-------

Reproducible within minutes by scrolling bright web pages. Frequency under
load is one event every 2-5 minutes. Recovery is usually ~2 s; three events
during the session took between 2 and 3 minutes.

Only the Studio Display blanks. A second monitor on HDMI is unaffected.

Trace
-----

drm.debug=0x104 plus "module thunderbolt +p". A single event:

  i915 0000:00:02.0: [drm:xelpdp_pica_irq_handler] pica hotplug event received,
                     stat 0x0000000c, pins 0x00001800, long 0x00001800
  i915 0000:00:02.0: [drm:intel_dp_hpd_pulse] got hpd irq on
                     [ENCODER:521:DDI TC3/PHY TC3] - long
  i915 0000:00:02.0: [drm:drm_dp_dpcd_access] AUX USBC3/DDI TC3/PHY TC3:
                     Too many retries, giving up. First error: -6
  i915 0000:00:02.0: [drm:intel_dp_hpd_pulse] got hpd irq on
                     [ENCODER:549:DDI TC4/PHY TC4] - long
  i915 0000:00:02.0: [drm:intel_tc_port_reset_mode] Port G/TC#4:
                     TC port mode reset (disconnected -> tbt-alt)
  i915 0000:00:02.0: [drm:drm_dp_tunnel_destroy] [DPTUN 1:1:5] destroying
  i915 0000:00:02.0: [drm:drm_dp_tunnel_destroy] [DPTUN 1:1:6] destroying

Thunderbolt side of the same event:

  thunderbolt 0000:00:0d.3: acking hot unplug event on 1:11
  thunderbolt 0000:00:0d.3: 1:11: DP OUT resource unavailable: adapter unplug
  thunderbolt 0000:00:0d.3: 0:5 <-> 1:11 (DP): deactivating
  thunderbolt 0000:00:0d.3: acking hot unplug event on 1:12
  thunderbolt 0000:00:0d.3: deactivating Video path from 0:5 to 1:11
  thunderbolt 0000:00:0d.3: 0:5: detached from bandwidth group 1
  thunderbolt 0000:00:0d.3: 0: released DP resource for port 5
  thunderbolt 0000:00:0d.3: 0:6 <-> 1:12 (DP): DPRX read timeout

The "hot unplug event" originates from the device router; the host acks it
and tears the tunnels down. "DPRX read timeout" recurs on every event.

In one earlier trace the teardown was preceded by a bandwidth-allocation
request from the display asking for zero:

  thunderbolt 0000:00:0d.3: acking DP_BW (0x20) notification on 0
  thunderbolt 0000:00:0d.3: 0:6: requested bandwidth 0 Mb/s
  thunderbolt 0000:00:0d.3: 0:6 <-> 1:12 (DP): bandwidth allocation
changed to 0/0 Mb/s
  thunderbolt 0000:00:0d.3: acking hot unplug event on 1:12

Later events start directly at the active adapter 1:11 with no such
prelude, also with bw_alloc_mode=N.

Possibly relevant: tunnel topology differs between the two models
-----------------------------------------------------------------

Both displays expose a 2x1 tiled EDID (2560x2880 per tile).

2026 model -- i915 drives the full 5120x2880 through a single tunnel at
HBR3; the second DP tunnel exists but never carries a stream:

  0:5 <-> 1:11 (DP): consumed bandwidth 0/22500 Mb/s      <- carries all of 5K
  0:6 <-> 1:12 (DP): consumed bandwidth 0/0 Mb/s          <- idle
  port_clock=810000, lane_count=4

2022 model -- driven as two real tiles, both tunnels carrying video:

  0:5 <-> 1:10 (DP): consumed bandwidth 0/17000 Mb/s
  0:6 <-> 1:11 (DP): estimated bandwidth 19000 Mb/s
  port_clock=540000, lane_count=4

The idle second tunnel of the 2026 model was the adapter that unplugged
first in the earliest traces.

Link maximum on this host is 36000 Mb/s. The tunnelled USB3 grows to
14738 Mb/s when DP releases bandwidth.

Ruled out
---------

Each of these was tested; the trace signature stayed byte-for-byte
identical.

- Display firmware update (performed via macOS; now NVM 64.81)
- thunderbolt.clx=0 -- link low-power states
- thunderbolt.bw_alloc_mode=0 -- DP bandwidth allocation mode
- Thunderbolt/PCIe runtime PM (power/control=on on the NHI controllers,
  the tunnel PCIe ports and all TB devices). This did eliminate a
  separate, rarer failure in which the whole TB link dropped for ~8 s
  including USB -- but has no effect on the DP-only events described here.
- Cable: swapped the 2026 display's cable for the 2022 display's TB3
  cable. Link still negotiates generation 4 at 20 Gb/s x 2; failure
  unchanged.
- Bandwidth / link training: AUX dies outright (-ENXIO), no retrain is
  ever attempted.
- PSR / Panel Replay: "Sink support: PSR = no, Panel Replay = no".

Not yet tested: driving the 2026 display as two explicit tiles to mirror
the 2022 model's working configuration.

Questions
---------

1. Is the host expected to tear down both DP tunnels when one DP OUT
   adapter signals unplug, or could the teardown be scoped to the
   affected adapter?
2. Would a debounce or retry be appropriate before releasing the DP
   resource, given the adapter reappears ~2 s later?
3. Is the recurring "DPRX read timeout" on this device a known interop
   issue? dprx_timeout is at its default of 12000 ms here.

Happy to test patches or collect further traces.

Thanks,
Bernd Behler

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

[Mika Westerberg]

Hi,

Great report!

On Sat, Aug 01, 2026 at 06:05:34PM +0200, Bernd Behler wrote:
> Summary
> -------
> 
> An Apple Studio Display (2026 model, Thunderbolt 5) connected to an Intel
> Arrow Lake-H host with integrated Thunderbolt 4 loses its DisplayPort
> tunnel every 2-5 minutes under normal desktop use. The screen goes black
> for ~2 s, occasionally for several minutes. The Thunderbolt link itself,
> the tunnelled USB3 and the tunnelled PCIe stay up throughout -- only the
> DP tunnels are torn down and re-established.
> 
> The previous Studio Display model (2022, Thunderbolt 3) on the same host,
> same port, same cable, same kernel does not show the problem.
> 
> Hardware
> --------
> 
> Host:        Intel NUC 15 Pro "Cyber Canyon" (NUC15CRKU5), Core Ultra 5 225H
> Host TB:     integrated, 8086:7ec2 / 8086:7ec3, host router generation 4
> GPU:         Intel Arc 130T/140T (8086:7d51), i915
> Kernel:      7.1.4-arch1-1 (Arch Linux)
> Compositor:  Hyprland / aquamarine (Wayland, atomic KMS)
> 
> Failing display -- Apple Studio Display 2026
> - EDID: manufacturer APP, model 44614, made week 1 of 2026
> - TB device 0x8025, generation 4, 20.0 Gb/s x 2 lanes, NVM 64.81
> - contains an Intel JHL9480 (Barlow Ridge, TB5) -- appears as
>   8086:5786 PCIe switch behind the tunnel
> - firmware updated via macOS immediately before these traces; no change
> 
> Working reference -- Apple Studio Display 2022
> - EDID: manufacturer APP, model 44602, made week 7 of 2022
> - TB device 0x801f, generation 3, NVM 67.0
> 
> Symptom
> -------
> 
> Reproducible within minutes by scrolling bright web pages. Frequency under
> load is one event every 2-5 minutes. Recovery is usually ~2 s; three events
> during the session took between 2 and 3 minutes.
> 
> Only the Studio Display blanks. A second monitor on HDMI is unaffected.
> 
> Trace
> -----
> 
> drm.debug=0x104 plus "module thunderbolt +p". A single event:
> 
>   i915 0000:00:02.0: [drm:xelpdp_pica_irq_handler] pica hotplug event received,
>                      stat 0x0000000c, pins 0x00001800, long 0x00001800
>   i915 0000:00:02.0: [drm:intel_dp_hpd_pulse] got hpd irq on
>                      [ENCODER:521:DDI TC3/PHY TC3] - long
>   i915 0000:00:02.0: [drm:drm_dp_dpcd_access] AUX USBC3/DDI TC3/PHY TC3:
>                      Too many retries, giving up. First error: -6
>   i915 0000:00:02.0: [drm:intel_dp_hpd_pulse] got hpd irq on
>                      [ENCODER:549:DDI TC4/PHY TC4] - long
>   i915 0000:00:02.0: [drm:intel_tc_port_reset_mode] Port G/TC#4:
>                      TC port mode reset (disconnected -> tbt-alt)
>   i915 0000:00:02.0: [drm:drm_dp_tunnel_destroy] [DPTUN 1:1:5] destroying
>   i915 0000:00:02.0: [drm:drm_dp_tunnel_destroy] [DPTUN 1:1:6] destroying
> 
> Thunderbolt side of the same event:
> 
>   thunderbolt 0000:00:0d.3: acking hot unplug event on 1:11
>   thunderbolt 0000:00:0d.3: 1:11: DP OUT resource unavailable: adapter unplug
>   thunderbolt 0000:00:0d.3: 0:5 <-> 1:11 (DP): deactivating
>   thunderbolt 0000:00:0d.3: acking hot unplug event on 1:12
>   thunderbolt 0000:00:0d.3: deactivating Video path from 0:5 to 1:11
>   thunderbolt 0000:00:0d.3: 0:5: detached from bandwidth group 1
>   thunderbolt 0000:00:0d.3: 0: released DP resource for port 5
>   thunderbolt 0000:00:0d.3: 0:6 <-> 1:12 (DP): DPRX read timeout
> 
> The "hot unplug event" originates from the device router; the host acks it
> and tears the tunnels down. "DPRX read timeout" recurs on every event.
> 
> In one earlier trace the teardown was preceded by a bandwidth-allocation
> request from the display asking for zero:
> 
>   thunderbolt 0000:00:0d.3: acking DP_BW (0x20) notification on 0
>   thunderbolt 0000:00:0d.3: 0:6: requested bandwidth 0 Mb/s
>   thunderbolt 0000:00:0d.3: 0:6 <-> 1:12 (DP): bandwidth allocation
> changed to 0/0 Mb/s
>   thunderbolt 0000:00:0d.3: acking hot unplug event on 1:12
> 
> Later events start directly at the active adapter 1:11 with no such
> prelude, also with bw_alloc_mode=N.
> 
> Possibly relevant: tunnel topology differs between the two models
> -----------------------------------------------------------------
> 
> Both displays expose a 2x1 tiled EDID (2560x2880 per tile).
> 
> 2026 model -- i915 drives the full 5120x2880 through a single tunnel at
> HBR3; the second DP tunnel exists but never carries a stream:
> 
>   0:5 <-> 1:11 (DP): consumed bandwidth 0/22500 Mb/s      <- carries all of 5K
>   0:6 <-> 1:12 (DP): consumed bandwidth 0/0 Mb/s          <- idle
>   port_clock=810000, lane_count=4
> 
> 2022 model -- driven as two real tiles, both tunnels carrying video:
> 
>   0:5 <-> 1:10 (DP): consumed bandwidth 0/17000 Mb/s
>   0:6 <-> 1:11 (DP): estimated bandwidth 19000 Mb/s
>   port_clock=540000, lane_count=4
> 
> The idle second tunnel of the 2026 model was the adapter that unplugged
> first in the earliest traces.
> 
> Link maximum on this host is 36000 Mb/s. The tunnelled USB3 grows to
> 14738 Mb/s when DP releases bandwidth.
> 
> Ruled out
> ---------
> 
> Each of these was tested; the trace signature stayed byte-for-byte
> identical.
> 
> - Display firmware update (performed via macOS; now NVM 64.81)
> - thunderbolt.clx=0 -- link low-power states
> - thunderbolt.bw_alloc_mode=0 -- DP bandwidth allocation mode
> - Thunderbolt/PCIe runtime PM (power/control=on on the NHI controllers,
>   the tunnel PCIe ports and all TB devices). This did eliminate a
>   separate, rarer failure in which the whole TB link dropped for ~8 s
>   including USB -- but has no effect on the DP-only events described here.
> - Cable: swapped the 2026 display's cable for the 2022 display's TB3
>   cable. Link still negotiates generation 4 at 20 Gb/s x 2; failure
>   unchanged.
> - Bandwidth / link training: AUX dies outright (-ENXIO), no retrain is
>   ever attempted.
> - PSR / Panel Replay: "Sink support: PSR = no, Panel Replay = no".
> 
> Not yet tested: driving the 2026 display as two explicit tiles to mirror
> the 2022 model's working configuration.
> 
> Questions
> ---------
> 
> 1. Is the host expected to tear down both DP tunnels when one DP OUT
>    adapter signals unplug, or could the teardown be scoped to the
>    affected adapter?

It should tear down the tunnel at that point.

> 2. Would a debounce or retry be appropriate before releasing the DP
>    resource, given the adapter reappears ~2 s later?

I don't think that is good solution. We should get bottom of this so adding
Imre Deak to take a look from DP side. Do you have full dmesg with the
debugging enabled available somewhere?

> 3. Is the recurring "DPRX read timeout" on this device a known interop
>    issue? dprx_timeout is at its default of 12000 ms here.

Those happen until GFX reads the capabilites through the DP tunnel - its
normal (well unless it times out completely in which case it tears down the
DP tunnel as well but I don't think that happens here).

> Happy to test patches or collect further traces.

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.

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):

  # tbtrace enable

  <repro the issue>

  # tbrace disable
  # tbtrace dump -vv > trace.out

You can find tbrace here [1]:

[1] https://github.com/intel/tbtools

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

[Bernd Behler]

[-- Attachment #1: Type: text/plain, Size: 4670 bytes --]

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

[-- Attachment #2: trace-tc3-domain1.out.xz --]
[-- Type: application/octet-stream, Size: 16772 bytes --]

[-- Attachment #3: dmesg-tc3-domain1.txt.xz --]
[-- Type: application/octet-stream, Size: 11296 bytes --]

[-- Attachment #4: trace-tc1-domain0.out.xz --]
[-- Type: application/octet-stream, Size: 16732 bytes --]

[-- Attachment #5: dmesg-tc1-domain0.txt.xz --]
[-- Type: application/octet-stream, Size: 11180 bytes --]

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

[Mika Westerberg]

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.

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

[Bernd Behler]

[-- Attachment #1: Type: text/plain, Size: 3328 bytes --]

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

[-- Attachment #2: trace-unplug-fast.out.xz --]
[-- Type: application/x-xz, Size: 4652 bytes --]

[-- Attachment #3: trace-unplug-mstoff.out.xz --]
[-- Type: application/x-xz, Size: 61392 bytes --]

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

[Mika Westerberg]

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.

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

[Bernd Behler]

Hi Mika,

> This is not expected. What typically happens is that there is another
> hotplug and the DP tunnels get re-established.

You are right and my observation was wrong — I had queried tbtunnels after
the re-establishment, not during the outage. It goes exactly as you describe,
about a second later:

  16:47:48  acking hot unplug event on 1:11
  16:47:48  1:11: DP OUT resource unavailable: adapter unplug
  16:47:48  0:5 <-> 1:11 (DP): deactivating
  16:47:48  acking hot unplug event on 1:12
  16:47:48  1:12: DP OUT resource unavailable: adapter unplug
  16:47:48  0:6 <-> 1:12 (DP): deactivating
  16:47:48  looking for DP IN <-> DP OUT pairs:
  16:47:48  0:5: no suitable DP OUT adapter available, not tunneling
  16:47:48  0:6: no suitable DP OUT adapter available, not tunneling
  16:47:49  1:11: DP OUT resource available after hotplug
  16:47:49  available bandwidth for new DP tunnel 34650/34650 Mb/s
  16:47:49  0:5 <-> 1:11 (DP): activating
  16:47:49  0:5 <-> 1:11 (DP): DP IN maximum supported bandwidth 8100
Mb/s x4 = 25920 Mb/s
  16:47:49  activating Video path from 0:5 to 1:11
  16:47:49  Video path activation complete
  16:47:50  1:12: DP OUT resource available after hotplug

So: unplug on both adapters, teardown, then a fresh hotplug on both and full
re-establishment roughly one second later. Nothing stale. Sorry for the noise.


Cable and power supply
----------------------

> Also, you connect the monitor with a real TB cable, right?
> The second idea that comes to mind is power supply

Both original Apple parts, and I can answer this better than by description,
because of how the desk is arranged: the NUC sits physically on top of a Mac
mini M2 Pro. Same room, same mains outlet, same monitor, same cable.

  cable plugged into the Mac mini underneath  ->  stable
  same cable plugged into the NUC above       ->  teardowns within minutes

Nothing moves except which host the plug goes into. That rules out the cable,
the monitor's power supply, and anything environmental. Note the Mac mini M2
Pro is Thunderbolt 4 as well, not 5, so this is not a TB5-sink-on-TB4-host
problem either.

The cable was additionally swapped for the 2022 unit's Thunderbolt cable
earlier; link still came up at generation 4 and the failure was unchanged.


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

Confirmed, always both, in the same millisecond bracket. The tunnelled USB3
and PCIe stay up throughout — only DP goes down. The monitor's USB hub,
webcam and speakers never disconnect during an event.


Usage pattern
-------------

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

Partly. Scrolling bright web pages full screen raises the rate noticeably and
is my usual way to provoke it. But it also happens with the machine idle and
nobody in the room, at a lower rate. So load correlates but is not required.

I am sorry to say I cannot run any more tests: the monitor goes back
today, so this
hardware is gone as of this afternoon and no further tests are possible on it.

What I do still have is everything captured while it was here — the traces
already sent, matching dmesg with drm.debug=0x104 plus thunderbolt dyndbg,
and full journals across several sessions. If any of that is worth a closer
look, or if you want a specific window extracted, just ask and I will dig it
out.


Bernd

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

[Mika Westerberg]

Hi,

On Wed, Aug 05, 2026 at 09:36:22AM +0200, Bernd Behler wrote:
> Hi Mika,
> 
> > This is not expected. What typically happens is that there is another
> > hotplug and the DP tunnels get re-established.
> 
> You are right and my observation was wrong — I had queried tbtunnels after
> the re-establishment, not during the outage. It goes exactly as you describe,
> about a second later:
> 
>   16:47:48  acking hot unplug event on 1:11
>   16:47:48  1:11: DP OUT resource unavailable: adapter unplug
>   16:47:48  0:5 <-> 1:11 (DP): deactivating
>   16:47:48  acking hot unplug event on 1:12
>   16:47:48  1:12: DP OUT resource unavailable: adapter unplug
>   16:47:48  0:6 <-> 1:12 (DP): deactivating
>   16:47:48  looking for DP IN <-> DP OUT pairs:
>   16:47:48  0:5: no suitable DP OUT adapter available, not tunneling
>   16:47:48  0:6: no suitable DP OUT adapter available, not tunneling
>   16:47:49  1:11: DP OUT resource available after hotplug
>   16:47:49  available bandwidth for new DP tunnel 34650/34650 Mb/s
>   16:47:49  0:5 <-> 1:11 (DP): activating
>   16:47:49  0:5 <-> 1:11 (DP): DP IN maximum supported bandwidth 8100
> Mb/s x4 = 25920 Mb/s
>   16:47:49  activating Video path from 0:5 to 1:11
>   16:47:49  Video path activation complete
>   16:47:50  1:12: DP OUT resource available after hotplug
> 
> So: unplug on both adapters, teardown, then a fresh hotplug on both and full
> re-establishment roughly one second later. Nothing stale. Sorry for the noise.

No worries.

> Cable and power supply
> ----------------------
> 
> > Also, you connect the monitor with a real TB cable, right?
> > The second idea that comes to mind is power supply
> 
> Both original Apple parts, and I can answer this better than by description,
> because of how the desk is arranged: the NUC sits physically on top of a Mac
> mini M2 Pro. Same room, same mains outlet, same monitor, same cable.
> 
>   cable plugged into the Mac mini underneath  ->  stable
>   same cable plugged into the NUC above       ->  teardowns within minutes
> 
> Nothing moves except which host the plug goes into. That rules out the cable,
> the monitor's power supply, and anything environmental. Note the Mac mini M2
> Pro is Thunderbolt 4 as well, not 5, so this is not a TB5-sink-on-TB4-host
> problem either.
> 
> The cable was additionally swapped for the 2022 unit's Thunderbolt cable
> earlier; link still came up at generation 4 and the failure was unchanged.

Okay. And if it was cable issue it would not trigger only DP OUT unplugs
but wanted to verify.

> > Based on your dump it also happens to both DP OUT adapters (11, 12) at the
> > same time.
> 
> Confirmed, always both, in the same millisecond bracket. The tunnelled USB3
> and PCIe stay up throughout — only DP goes down. The monitor's USB hub,
> webcam and speakers never disconnect during an event.
> 
> 
> Usage pattern
> -------------
> 
> > You don't see any "usage" pattern there when this happens?
> 
> Partly. Scrolling bright web pages full screen raises the rate noticeably and
> is my usual way to provoke it. But it also happens with the machine idle and
> nobody in the room, at a lower rate. So load correlates but is not required.
> 
> I am sorry to say I cannot run any more tests: the monitor goes back
> today, so this
> hardware is gone as of this afternoon and no further tests are possible on it.

Understood.

> What I do still have is everything captured while it was here — the traces
> already sent, matching dmesg with drm.debug=0x104 plus thunderbolt dyndbg,
> and full journals across several sessions. If any of that is worth a closer
> look, or if you want a specific window extracted, just ask and I will dig it
> out.

If you can put one full dmesg + trace somewhere that I could take a look
that would be great. Basically from the whole boot up to and including the
first double DP OUT unplugs. Maybe there is still something that could
point us to the culprit?