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