thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

[Dennis Wang]

Hi,

On most cold boots of this machine the connection manager gives up
permanently on DP tunnel establishment while the attached display is
still settling after the host-side link reset (the display stays powered
across host reboots; what matters seems to be whether it has recently
completed a successful bring-up with some host). Recovery only happens if
the display times out (tens of seconds) and resets its own TB link, producing
a fresh hotplug; when that doesn't happen the screen stays black until the
cable is replugged. The same display on a macOS host connects immediately,
and "warming" the display on a Mac and then replugging it into this Linux
host also connects immediately - so this looks like a host-side retry-policy
difference rather than a link-capability problem.

Hardware
--------
- Host: ASUS NUC 16 Pro, Core Ultra X9 388H (Panther Lake),
  integrated TB4 host router (8086:e433 DMA0), Intel retimer 8087:d9c
- Display: Apple Studio Display XDR (2026 model, TB5 upstream, 5K@120,
  internal hub is Intel JHL9480 Barlow Ridge [8086:5786])
- Cables tested:
  * Apple passive TB5 cable  -> link trains Gen3 x2 (40G total)
  * generic USB4 20G cable   -> link trains Gen2 x2 (20G total)
- Kernel: 7.1.8-arch1-3 (Arch Linux), xe graphics
- Software CM; bw_alloc_mode active; display requests TWO DP tunnels
  (main sink 12750 Mb/s with DSC for 5K120, second sink)

Failure case (cold boot, TB5 cable, default loglevel)
-----------------------------------------------------
[  289.341041] thunderbolt 0-1: new device found, vendor=0x1 device=0x8024
[  289.341073] thunderbolt 0-1: Apple Studio Display XDR
[  289.342256] thunderbolt 0000:00:0d.2: 1: failed to enable TMU
[  289.342321] thunderbolt 0000:00:0d.2: 1: USB3 tunnel creation failed
[  289.342383] thunderbolt 0000:00:0d.2: 1:11: DP tunnel activation
failed, aborting
   (x4)
[  289.342748] thunderbolt 0-1: device disconnected
[  289.343325] thunderbolt 0-1: new device found ...      (bounces to 0-3)
[  289.363303] thunderbolt 0000:00:0d.2: 0:10 <-> 3:12 (DP): not
enough bandwidth
[  289.363367] thunderbolt 0000:00:0d.2: 3:12: DP tunnel activation
failed, aborting
   ... at least ~54 s of silence, no retry from the CM ...
[  343.614848] thunderbolt 0-3: device disconnected       (display firmware
[  348.801013] thunderbolt 0-1: new device found ...       resets itself)
   ... this attempt succeeds silently, display lights up
(Note: early timestamps above are journald ingest times - root fs is
encrypted, so initramfs-stage kmsg is re-stamped after unlock.)

xe reports matching "[CONNECTOR:512:DP-1] commit wait timed out" +
intel_dp_link_check WARNs during the failed window.

Observations
------------
1. Every failed attempt ends at tb_tunnel_one_dp() ->
   "DP tunnel activation failed, aborting". Nothing is rescheduled;
   the only recovery path is a fresh hotplug generated by the display
   itself. On a bad day the display doesn't reset and the black screen
   is permanent (needs replug / display power cycle).
2. Hot-plug of the warm display succeeds 100% of the time on both cables
   (40G on the TB5 cable, 5K120 DSC fine).
3. A successful cold boot captured with thunderbolt.dyndbg=+p (USB4 20G
   cable) still shows 2 disconnect/reconnect cycles and one transient
   "not enough bandwidth" for the second DP tunnel before converging -
   success vs failure appears to be the same bounce loop with a lucky
   final iteration, not a different path.
4. thunderbolt.clx=0 makes the "failed to enable TMU" line disappear but
   does not change the user-visible behavior.

Question
--------
Would a bounded retry with backoff in the DP tunnel setup path be an
acceptable direction? I.e. on activation failure / NO_BANDWIDTH in
tb_tunnel_one_dp(), schedule delayed work that re-runs tb_tunnel_dp()
a few times (cancelled on unplug) instead of aborting permanently.
Notably the driver already applies exactly this pattern to
bandwidth-allocation requests that arrive before the tunnel is active
(TB_BW_ALLOC_RETRIES, 50 ms backoff in tb_queue_dp_bandwidth_request());
tunnel establishment just has no equivalent today.
I'm happy to test patches on this hardware, and can provide:
- full dyndbg log of the successful cold boot (3900 lines, on hand)
- dyndbg capture of a failing cold boot (can reproduce)
- anything else that helps (this combination - Panther Lake TB4 host +
  Barlow Ridge based TB5 display - is probably rare right now)

Thanks,
Dennis Wang

Re: thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

[Mika Westerberg]

Hi,

On Sun, Aug 23, 2026 at 11:24:40PM +0800, Dennis Wang wrote:
> Hi,
> 
> On most cold boots of this machine the connection manager gives up
> permanently on DP tunnel establishment while the attached display is
> still settling after the host-side link reset (the display stays powered
> across host reboots; what matters seems to be whether it has recently
> completed a successful bring-up with some host). Recovery only happens if
> the display times out (tens of seconds) and resets its own TB link, producing
> a fresh hotplug; when that doesn't happen the screen stays black until the
> cable is replugged. The same display on a macOS host connects immediately,
> and "warming" the display on a Mac and then replugging it into this Linux
> host also connects immediately - so this looks like a host-side retry-policy
> difference rather than a link-capability problem.
> 
> Hardware
> --------
> - Host: ASUS NUC 16 Pro, Core Ultra X9 388H (Panther Lake),
>   integrated TB4 host router (8086:e433 DMA0), Intel retimer 8087:d9c
> - Display: Apple Studio Display XDR (2026 model, TB5 upstream, 5K@120,
>   internal hub is Intel JHL9480 Barlow Ridge [8086:5786])
> - Cables tested:
>   * Apple passive TB5 cable  -> link trains Gen3 x2 (40G total)
>   * generic USB4 20G cable   -> link trains Gen2 x2 (20G total)
> - Kernel: 7.1.8-arch1-3 (Arch Linux), xe graphics
> - Software CM; bw_alloc_mode active; display requests TWO DP tunnels
>   (main sink 12750 Mb/s with DSC for 5K120, second sink)
> 
> Failure case (cold boot, TB5 cable, default loglevel)
> -----------------------------------------------------
> [  289.341041] thunderbolt 0-1: new device found, vendor=0x1 device=0x8024
> [  289.341073] thunderbolt 0-1: Apple Studio Display XDR
> [  289.342256] thunderbolt 0000:00:0d.2: 1: failed to enable TMU
> [  289.342321] thunderbolt 0000:00:0d.2: 1: USB3 tunnel creation failed
> [  289.342383] thunderbolt 0000:00:0d.2: 1:11: DP tunnel activation
> failed, aborting
>    (x4)
> [  289.342748] thunderbolt 0-1: device disconnected
> [  289.343325] thunderbolt 0-1: new device found ...      (bounces to 0-3)
> [  289.363303] thunderbolt 0000:00:0d.2: 0:10 <-> 3:12 (DP): not
> enough bandwidth
> [  289.363367] thunderbolt 0000:00:0d.2: 3:12: DP tunnel activation
> failed, aborting
>    ... at least ~54 s of silence, no retry from the CM ...
> [  343.614848] thunderbolt 0-3: device disconnected       (display firmware
> [  348.801013] thunderbolt 0-1: new device found ...       resets itself)
>    ... this attempt succeeds silently, display lights up
> (Note: early timestamps above are journald ingest times - root fs is
> encrypted, so initramfs-stage kmsg is re-stamped after unlock.)
> 
> xe reports matching "[CONNECTOR:512:DP-1] commit wait timed out" +
> intel_dp_link_check WARNs during the failed window.
> 
> Observations
> ------------
> 1. Every failed attempt ends at tb_tunnel_one_dp() ->
>    "DP tunnel activation failed, aborting". Nothing is rescheduled;
>    the only recovery path is a fresh hotplug generated by the display
>    itself. On a bad day the display doesn't reset and the black screen
>    is permanent (needs replug / display power cycle).
> 2. Hot-plug of the warm display succeeds 100% of the time on both cables
>    (40G on the TB5 cable, 5K120 DSC fine).
> 3. A successful cold boot captured with thunderbolt.dyndbg=+p (USB4 20G
>    cable) still shows 2 disconnect/reconnect cycles and one transient
>    "not enough bandwidth" for the second DP tunnel before converging -
>    success vs failure appears to be the same bounce loop with a lucky
>    final iteration, not a different path.
> 4. thunderbolt.clx=0 makes the "failed to enable TMU" line disappear but
>    does not change the user-visible behavior.
> 
> Question
> --------
> Would a bounded retry with backoff in the DP tunnel setup path be an
> acceptable direction? I.e. on activation failure / NO_BANDWIDTH in
> tb_tunnel_one_dp(), schedule delayed work that re-runs tb_tunnel_dp()
> a few times (cancelled on unplug) instead of aborting permanently.
> Notably the driver already applies exactly this pattern to
> bandwidth-allocation requests that arrive before the tunnel is active
> (TB_BW_ALLOC_RETRIES, 50 ms backoff in tb_queue_dp_bandwidth_request());
> tunnel establishment just has no equivalent today.
> I'm happy to test patches on this hardware, and can provide:
> - full dyndbg log of the successful cold boot (3900 lines, on hand)
> - dyndbg capture of a failing cold boot (can reproduce)
> - anything else that helps (this combination - Panther Lake TB4 host +
>   Barlow Ridge based TB5 display - is probably rare right now)

[Added Imre.]

There was recently another report about the same monitor but we could not
root cause the issue because the reporter had to return the display. I
think the problem happened also when plugging the monitor in after the
system was already up.

Can you provide a full dmesg of the cold boot with dyndgb enabled? Please
also add "drm.debug=0x10e" in the command like so we can get the graphics
side logs as well.

Re: thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

[Dennis Wang]

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

Hi Mika, Imre,

Attached: cold boot dmesg with thunderbolt.dyndbg=+p + drm.debug=0x10e
(timestamps rebuilt from _SOURCE_MONOTONIC_TIMESTAMP; root fs is LUKS
so journald re-stamps initramfs kmsg).

This boot hit the graphics-side flavor - tunnels healthy, screen black
until the LUKS passphrase was typed blind at ~40 s:

  1.8s   XDR found, Gen3 x2, both DP tunnels allocated, no errors
  3.9s   second sink (0:10 <-> 3:12): repeated "DPRX read timeout"
         (tiled 2x1 panel, two DP sinks)
  3.96s  fastset rejected: crtc_hblank_start expected 3840, found 1920
  11.3s  AUX_TC2 power well disabled - nothing lights the panel again
         until the compositor modeset after unlock (~60 s)

A control cold boot with video=DP-2:d (masking the second sink) is
fully clean, panel lit at ~4 s, single-stream 5K120 DSC. The original
"DP tunnel activation failed" flavor is intermittent - will send it
with full debug when I catch it.

Happy to test patches on this hardware.

Thanks,
Dennis Wang

[-- Attachment #2: dmesg-source-ts.txt.xz --]
[-- Type: application/x-xz, Size: 74304 bytes --]

Re: thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

[Imre Deak]

Hi Dennis,

thanks for the logs.

Could you confirm that the problem you see is:

After boot-up with both displays connected, one of the display is blank
by 4.839037, while the other display lights up okay.

By 47.768154 both displays light up correctly.

I can't see any obvious issues related to tunneling, both tunnels are
detected and the BW allocations for them succeed as expected.

Could you try if the same sequence without the other issue you mentioned
happening (DP tunnel activation failed) the blank screen problem
reproduces booting with: xe.enable_fbc=0 ?

Thanks,
Imre

On Tue, Aug 25, 2026 at 09:42:23AM +0800, Dennis Wang wrote:
> Hi Mika, Imre,
> 
> Attached: cold boot dmesg with thunderbolt.dyndbg=+p + drm.debug=0x10e
> (timestamps rebuilt from _SOURCE_MONOTONIC_TIMESTAMP; root fs is LUKS
> so journald re-stamps initramfs kmsg).
> 
> This boot hit the graphics-side flavor - tunnels healthy, screen black
> until the LUKS passphrase was typed blind at ~40 s:
> 
>   1.8s   XDR found, Gen3 x2, both DP tunnels allocated, no errors
>   3.9s   second sink (0:10 <-> 3:12): repeated "DPRX read timeout"
>          (tiled 2x1 panel, two DP sinks)
>   3.96s  fastset rejected: crtc_hblank_start expected 3840, found 1920
>   11.3s  AUX_TC2 power well disabled - nothing lights the panel again
>          until the compositor modeset after unlock (~60 s)
> 
> A control cold boot with video=DP-2:d (masking the second sink) is
> fully clean, panel lit at ~4 s, single-stream 5K120 DSC. The original
> "DP tunnel activation failed" flavor is intermittent - will send it
> with full debug when I catch it.
> 
> Happy to test patches on this hardware.
> 
> Thanks,
> Dennis Wang

Re: thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

[Dennis Wang]

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

Hi Imre,

One clarification first: there is only one physical display - an Apple
Studio Display XDR, a tiled 2x1 panel with two DP sinks, hence the two
tunnels/connectors in the logs. The whole panel stays black from
power-on until I type the LUKS passphrase blind; the compositor modeset
after unlock is what first lights it. So it is not one display lighting
up while another stays dark.

Tested xe.enable_fbc=0 on a cold boot with both sinks active: panel
still black until the compositor modeset (~83s). In that boot I noticed
Panel Replay enabled at 4.7s and disabled at 81.6s, bracketing the
black window exactly, so I also tried xe.enable_panel_replay=0: still
black (until ~123s that time).

What both logs show: the fbdev client's tiled two-pipe modeset
completes without errors - links train at 5.4G x4, both tunnels get
17000 Mb/s allocated, transcoders enable (in the fbc=0 boot both pipes
are up by 4.7s) - yet nothing ever appears on the panel. The first
modeset that visibly lights it is the compositor's single-stream
5120x2880 DSC config after unlock.

Consistent with that: booting with video=DP-2:d (second sink masked,
single-stream from the start) is fully clean on every boot, LUKS prompt
visible at ~4s.

Both dmesgs attached (timestamps rebuilt from
_SOURCE_MONOTONIC_TIMESTAMP as before). Happy to test patches or more
knobs.

Thanks,
Dennis

Imre Deak <imre.deak@intel.com> 于2026年8月25日周二 17:35写道：
>
>
> Hi Dennis,
>
> thanks for the logs.
>
> Could you confirm that the problem you see is:
>
> After boot-up with both displays connected, one of the display is blank
> by 4.839037, while the other display lights up okay.
>
> By 47.768154 both displays light up correctly.
>
> I can't see any obvious issues related to tunneling, both tunnels are
> detected and the BW allocations for them succeed as expected.
>
> Could you try if the same sequence without the other issue you mentioned
> happening (DP tunnel activation failed) the blank screen problem
> reproduces booting with: xe.enable_fbc=0 ?
>
> Thanks,
> Imre
>
> On Tue, Aug 25, 2026 at 09:42:23AM +0800, Dennis Wang wrote:
> > Hi Mika, Imre,
> >
> > Attached: cold boot dmesg with thunderbolt.dyndbg=+p + drm.debug=0x10e
> > (timestamps rebuilt from _SOURCE_MONOTONIC_TIMESTAMP; root fs is LUKS
> > so journald re-stamps initramfs kmsg).
> >
> > This boot hit the graphics-side flavor - tunnels healthy, screen black
> > until the LUKS passphrase was typed blind at ~40 s:
> >
> >   1.8s   XDR found, Gen3 x2, both DP tunnels allocated, no errors
> >   3.9s   second sink (0:10 <-> 3:12): repeated "DPRX read timeout"
> >          (tiled 2x1 panel, two DP sinks)
> >   3.96s  fastset rejected: crtc_hblank_start expected 3840, found 1920
> >   11.3s  AUX_TC2 power well disabled - nothing lights the panel again
> >          until the compositor modeset after unlock (~60 s)
> >
> > A control cold boot with video=DP-2:d (masking the second sink) is
> > fully clean, panel lit at ~4 s, single-stream 5K120 DSC. The original
> > "DP tunnel activation failed" flavor is intermittent - will send it
> > with full debug when I catch it.
> >
> > Happy to test patches on this hardware.
> >
> > Thanks,
> > Dennis Wang
>
>


-- 
Best Regards
Dennis.Wang
Zoom

[-- Attachment #2: dmesg-source-ts.txt.xz --]
[-- Type: application/x-xz, Size: 69592 bytes --]

[-- Attachment #3: dmesg-source-ts.txt.xz --]
[-- Type: application/x-xz, Size: 69692 bytes --]

Re: thunderbolt: DP tunnel activation not retried when display NAKs while settling after link reset (Apple Studio Display XDR 2026 on Panther Lake)

[Imre Deak]

On Tue, Aug 25, 2026 at 10:11:53PM +0800, Dennis Wang wrote:
> Hi Imre,
> 
> One clarification first: there is only one physical display - an Apple
> Studio Display XDR, a tiled 2x1 panel with two DP sinks, hence the two
> tunnels/connectors in the logs. The whole panel stays black from
> power-on until I type the LUKS passphrase blind; the compositor modeset
> after unlock is what first lights it. So it is not one display lighting
> up while another stays dark.
> 
> Tested xe.enable_fbc=0 on a cold boot with both sinks active: panel
> still black until the compositor modeset (~83s). In that boot I noticed
> Panel Replay enabled at 4.7s and disabled at 81.6s, bracketing the
> black window exactly, so I also tried xe.enable_panel_replay=0: still
> black (until ~123s that time).
> 
> What both logs show: the fbdev client's tiled two-pipe modeset
> completes without errors - links train at 5.4G x4, both tunnels get
> 17000 Mb/s allocated, transcoders enable (in the fbc=0 boot both pipes
> are up by 4.7s) - yet nothing ever appears on the panel. The first
> modeset that visibly lights it is the compositor's single-stream
> 5120x2880 DSC config after unlock.

Thanks. 

Not sure what could be wrong with the fbdev modeset, no obvious issues
in the logs around that.

The later compositor modeset config is a bit strange: one pipe is
enabled with a 5120x2880 mode and another pipe with a 2560x2880 mode, as
if the tile configuration would be ignored. Could you check what's the
compositor's idea of the monitors and modes and try to set a 2560x2880
mode (after booting with disabling both fbc and panel replay)?

I think it'd be easier to follow up on a ticket, could you please open
one at

https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/new?type=Issue

and attach the log after setting the above 2560x2880 mode?

Could you also attach the log there when booting with video=DP-2:d?

> Consistent with that: booting with video=DP-2:d (second sink masked,
> single-stream from the start) is fully clean on every boot, LUKS prompt
> visible at ~4s.
> 
> Both dmesgs attached (timestamps rebuilt from
> _SOURCE_MONOTONIC_TIMESTAMP as before). Happy to test patches or more
> knobs.
> 
> Thanks,
> Dennis
> 
> Imre Deak <imre.deak@intel.com> 于2026年8月25日周二 17:35写道：
> >
> >
> > Hi Dennis,
> >
> > thanks for the logs.
> >
> > Could you confirm that the problem you see is:
> >
> > After boot-up with both displays connected, one of the display is blank
> > by 4.839037, while the other display lights up okay.
> >
> > By 47.768154 both displays light up correctly.
> >
> > I can't see any obvious issues related to tunneling, both tunnels are
> > detected and the BW allocations for them succeed as expected.
> >
> > Could you try if the same sequence without the other issue you mentioned
> > happening (DP tunnel activation failed) the blank screen problem
> > reproduces booting with: xe.enable_fbc=0 ?
> >
> > Thanks,
> > Imre
> >
> > On Tue, Aug 25, 2026 at 09:42:23AM +0800, Dennis Wang wrote:
> > > Hi Mika, Imre,
> > >
> > > Attached: cold boot dmesg with thunderbolt.dyndbg=+p + drm.debug=0x10e
> > > (timestamps rebuilt from _SOURCE_MONOTONIC_TIMESTAMP; root fs is LUKS
> > > so journald re-stamps initramfs kmsg).
> > >
> > > This boot hit the graphics-side flavor - tunnels healthy, screen black
> > > until the LUKS passphrase was typed blind at ~40 s:
> > >
> > >   1.8s   XDR found, Gen3 x2, both DP tunnels allocated, no errors
> > >   3.9s   second sink (0:10 <-> 3:12): repeated "DPRX read timeout"
> > >          (tiled 2x1 panel, two DP sinks)
> > >   3.96s  fastset rejected: crtc_hblank_start expected 3840, found 1920
> > >   11.3s  AUX_TC2 power well disabled - nothing lights the panel again
> > >          until the compositor modeset after unlock (~60 s)
> > >
> > > A control cold boot with video=DP-2:d (masking the second sink) is
> > > fully clean, panel lit at ~4 s, single-stream 5K120 DSC. The original
> > > "DP tunnel activation failed" flavor is intermittent - will send it
> > > with full debug when I catch it.
> > >
> > > Happy to test patches on this hardware.
> > >
> > > Thanks,
> > > Dennis Wang
> >
> >
> 
> 
> -- 
> Best Regards
> Dennis.Wang
> Zoom