Kernel panic Studio Display XDR + M2 Max MacBook Pro at 5K@120Hz (DCPEXT1 dual_pipe.c:180 sync_pipe_end_of_config)

Question

Level 1

36 points

Kernel panic Studio Display XDR + M2 Max MacBook Pro at 5K@120Hz (DCPEXT1 dual_pipe.c:180 sync_pipe_end_of_config)

I'm experiencing repeated kernel panics with my Studio Display XDR connected to a MacBook Pro M2 Max (Mac14,6) running macOS Tahoe 26.3.1 (25D2128). Three identical panics in three days.

CONFIGURATION:

MacBook Pro 16" M2 Max (Mac14,6)
macOS 26.3.1 (25D2128)
Studio Display XDR (serial: ***, firmware Version 26.3, Build 23D8128)
Connected via Thunderbolt/USB4 at 40 Gb/s (Bus 0, Receptacle 1)
Resolution: 5120x2880 @ 120Hz (ProMotion)
"Automatically Adjust Brightness" enabled
Use left rear port, might have tested with others too

This is a supported configuration — Apple's compatibility page confirms M2 Max supports Studio Display XDR at full 120Hz. The 60Hz limitation only applies to M1, M1 Pro, M1 Max, M1 Ultra, M2 (base), and M3 (base).

SYMPTOMS:

The Mac reboots unexpectedly with no warning. After restart, a kernel panic report is generated. The crash occurs every 1-2 days during normal use. It seems to correlate with display sleep/wake transitions but I haven't been able to pinpoint an exact trigger.

PANIC SIGNATURE (identical across all 3 crashes):

DCPEXT1 PANIC - apt firmware: dual_pipe.c:180 sync_pipe_end_of_config() -- - iomfb_mailbox(71)

DCP firmware: AppleDCP-1041.91.2~2-t602xdcp.RELEASE
RTKit build: root@Jan 17 2026@08:47:45~.release

The crash is in the Display Coprocessor (DCP) firmware running on the RTKit RTOS — specifically in the dual-pipe synchronisation code path. The 5K panel at 120Hz requires the DCP to split the display into two pipes, and the sync between them fails. The faulting task is always task 71 (iomfb_mailbox).

Kernel extensions in backtrace:

com.apple.driver.RTBuddy(1.0)
com.apple.driver.IOSlaveProcessor(1.0)

PANIC DATES:

2026-03-15 07:42:58 UTC (incident: 5705E8C5-EF4A-4AC7-90A2-1C13E88FF5B2)
2026-03-15 17:05:48 UTC (incident: 2D4FD13D-F65A-43C7-B8EB-2ECD168BEFCD)
2026-03-17 19:57:58 UTC (incident: 2293C922-19D3-4464-96AD-1DACE7E21BE4)

WHAT I'VE RULED OUT:

Hardware defect: The crash is in DCP firmware, not hardware. The Thunderbolt link is solid at 40 Gb/s.
Cable issue: Connection is stable, no link errors.
GPU load: Crashes happen during normal use, not under heavy GPU load.
This would reproduce on any Apple Silicon Mac that supports this display at 120Hz, since all Macs running macOS 26.3.1 load the same DCP firmware (AppleDCP-1041.91.2~2).

WORKAROUND (which I will not be using):

Setting the refresh rate from "ProMotion" to "60 Hertz" might prevent the panic by avoiding the dual-pipe code path. However, I did not spend £3,000 on this display to run it at 60Hz. 120Hz ProMotion is a headline feature of the Studio Display XDR and a primary reason I purchased it. Running it at 60Hz makes it functionally equivalent to the original Studio Display at a fraction of the price.

I will be returning this display. It's not acceptable that a supported configuration on Apple's own hardware causes kernel panics every 1-2 days. If Apple resolves this with a firmware update, I'd consider repurchasing, but I can't keep a £3,000 monitor that crashes my Mac.

RELATED THREADS:

This appears to be the same underlying bug reported with third-party 4K@240Hz monitors:

The common pattern across all these reports: high refresh rates that push the DCP into dual-pipe mode trigger sync_pipe_end_of_config() failures. Multiple users report the bug was introduced with macOS Sequoia and did not occur on Sonoma.

I've filed a Feedback Assistant report with all 3 panic logs and a sysdiagnose. If you're experiencing the same crash, please file as well to help Apple prioritise a fix.

Is anyone else seeing this specifically with the Studio Display XDR at 120Hz?

[Edited by Moderator]

MacBook Pro 16″, macOS 26.3

Posted on Mar 17, 2026 3:35 PM

Reply

Answer 1

amarjeetr Author

Level 1

36 points

Mar 17, 2026 4:47 PM in response to amarjeetr

UPDATE: Tested on an M4 Max MacBook Pro (Thunderbolt 5, 80 Gbps). Despite the

faster link, the DisplayPort tunnel still negotiates HBR3 (8.1 Gbps/lane) because

the Studio Display XDR's receiver only supports DP 1.4a. DSC is used to compress

the stream to fit.

However, the M4 Max shows 5K@120Hz as single-pipe (HorizontalPipeCount=1) in its

timing table, while the M2 Max shows it as dual-pipe (HorizontalPipeCount=2). This

suggests the bug may be specific to the M2-generation DCP firmware (t602xdcp), as

the M4 Max DCP firmware (t604xdcp) handles the same mode without requiring dual-pipe.

The M4 Max has not crashed so far, though testing is ongoing.

Seems like Apple needs to fix their dual-pipe firmware.

Reply

Answer 2

Mar 19, 2026 7:30 AM in response to amarjeetr

I am having the exact same problem. But in my case, it is the the Mac Studio M2 Ultra and the Mac Studio M2 Ultra combination.

From My research and what I think is going on is as follows;

The Studio Display XDR only supports a single upstream Thunderbolt connection, so using two cables is not a viable configuration. macOS is handling the bandwidth requirement internally by using dual-pipe mode on M2-generation systems.

The kernel panic isn’t due to insufficient bandwidth or cabling in my educated opinion. I believe the system successfully negotiates and runs 5K @ 120Hz. The failure occurs inside the DCP firmware during the dual-pipe synchronization step (sync_pipe_end_of_config()), which suggests a firmware issue rather than a transport limitation.

There’s also evidence that newer Macs (e.g. M4 Max) can drive the same display mode using a single pipe with DSC, avoiding the dual-pipe path entirely and not exhibiting this crash. That points more toward a generation-specific DCP firmware issue than a Thunderbolt bandwidth constraint.

So at this point, it seems less about cabling and more about how the M2 display pipeline is implemented in current firmware.

Reply

Answer 3

amarjeetr Author

Level 1

36 points

Mar 19, 2026 11:51 AM in response to amarjeetr

UPDATE:

So after a couple of days with Apple support, and sending over data for them to debug. I’ve been told by the support team, the internal team has acknowledged this is indeed a software issue and that they will look at fixing it but no ETA and no way to track this or for them notify me. So I will be returning it. No way I’m running it at 60Hz.

Reply

Answer 4

Mar 19, 2026 9:07 AM in response to amarjeetr

Same thing happened to me. I have a MacBook Pro M2 Max, and the screen glitched and crashed. I switched from adaptive to 120Hz fixed, and it weirdly hasn’t crashed yet. I think it’s a firmware problem they need to fix.

Reply

Answer 5

Mar 25, 2026 12:21 AM in response to amarjeetr

True. Apple has now released both macOS 26.4 and Studio Display XDR firmware 26.4, which is encouraging. But there is still no clear evidence yet that either update fixes the 120Hz / Adaptive crash issue.

The display firmware update matters because it updates code on the monitor itself, while macOS updates the Mac-side display stack and DCP behavior. Since these crashes appear tied to the interaction between the Mac’s display pipeline and the display at adaptive and high refresh rates, it may take both sides being updated before the issue is resolved.

That said, without release notes mentioning 120Hz, Adaptive refresh, dual-pipe sync, or DCP stability, we still cannot assume the problem is fixed. The only real way to know is to test carefully.

Reply

Answer 6

Mar 19, 2026 12:09 PM in response to amarjeetr

Thanks for the update. This is actually really helpful to hear.

It lines up with what a few of us were seeing from the panic logs and behavior. The system can clearly drive 5K @ 120Hz, but the crashes happen in the display pipeline during reconfiguration/sync, which points more to a software/firmware issue than anything related to cables or bandwidth.

Unfortunate there’s no ETA though. I think your decision to return makes sense because running a display like this at 60Hz just to keep it stable isn’t really acceptable. Hopefully Apple addresses it soon, because the hardware itself is clearly capable.

Reply

Answer 7

amarjeetr Author

Level 1

36 points

Mar 18, 2026 3:41 PM in response to Dfewgoodmen

Yes. The issue is on my personal M2 Max which because of bandwidth or something splits the screen in two (dual-pipe). So they have to be synced and supposedly that’s where the issue lies (in macOS software). Ideally, this buggy they should never have said it supports 120Hz, but it can be great if they iron out the bugs.

On the M4 Max (my work laptop), there’s no issues because it a single pipe using compression. So there haven’t been any crashes.

I did this analysis with Claude code / OpenCode.

Reply

Answer 8

Mar 19, 2026 7:35 AM in response to amarjeetr

That’s a really solid analysis. It lines up closely with what I’m seeing as well.

One small nuance I’d add: it doesn’t seem to be a raw “bandwidth limit” issue in the sense of the link failing, since the system is clearly able to negotiate and run 5K @ 120Hz. The crash is intermittent. Only a few times a day.

From observation, the crash only happens after that, during the dual-pipe sync step (sync_pipe_end_of_config()), which points more to a firmware/driver issue than a transport constraint.

Your M4 vs M2 comparison is especially interesting. If the M4 can do the same mode in single-pipe with DSC, that would explain why it avoids the crash entirely — it never touches the dual-pipe path that seems to be unstable on M2.

So I’d agree with your conclusion: this feels like a DCP firmware issue specific to the M2 generation rather than something inherently wrong with the display or cable.

I agree totally with you on the 120Hz point. If it’s exposed as a supported mode, it really shouldn’t be capable of triggering a kernel panic in normal use.

Reply

Answer 9

May 21, 2026 8:46 AM in response to Krist3nz

Krist3nz wrote:

• I’m seeing the exact same issue on my side with a similar panic signature, even after updating to the latest firmware/macOS versions.

My setup:

MacBook Pro M5 Pro (26.4.1)

• Studio Display XDR (firmware 26.4)

The panic is still:

DCPEXT0/1 PANIC - dual_pipe.c sync_pipe_end_of_config()

Is there any updates from Apple or any improvement since posting this?

FYI, Actually macOS 26.5 was released last week. You are one update behind on patches.

Reply

Answer 10

Mar 20, 2026 10:49 AM in response to caustinmac

That’s helpful to hear, and it aligns with what many of us are seeing. That it does look like a software/firmware issue rather than hardware.

I’ve just installed the Apple's latest Background Security update (26.3.1 (a)) available for Mac OS, but I’m not expecting it to fix anything though. These updates are typically security patches, not changes to the display pipeline or DCP firmware where this issue seems to be.

What’s surprising is that there are now reports even on newer chips (M4 Max), And you now mention also M5 chips as well !! To me, this may suggest the problem may not be limited to M2 as initially thought. And with your experience, it does raises the concern that this is a broader issue with how macOS is handling 5K@120Hz rather than a single-generation limitation.

At this point, it feels like no M-series device is fully “safe” from this until Apple addresses the underlying display pipeline/firmware behavior. 60Hz avoids the problem, but obviously that’s not why anyone including me bought this display.

Agree with your decision: without a fix or timeline, it’s hard to justify keeping it.

Reply

Answer 11

Mar 23, 2026 6:49 PM in response to amarjeetr

Experienced this multiple times running at Adaptive on M4 Pro. Switched to 120 Hz today and haven’t had the kernel panic again so far. Single ASD XDR connected via the stock Thunderbolt 5 cable, macOS 26.3.1(a).

Reply

Answer 12

Mar 27, 2026 5:55 PM in response to caustinmac

Do you experience the crash only at Adaptive, or fixed 120 Hz as well?

caustinmac wrote:

this hasn't fixed the issue for me. i still get the screen corruption + MBP crash 1-2 times per day. there's also a new thing now where the display will turn off for 2-3 seconds and my desktop moves over to the MBP screen - and then comes back when the display comes back. (feels like the display restarted maybe?) [new MBP M5 + Studio XDR]

Reply

Answer 13

Apr 21, 2026 11:02 AM in response to amarjeetr

I replaced my Studio Display XDR unit, everything on latest version (26.4 monitor firmware and 26.4.1 on my M4 Max Mac Studio), and after 10 days without issue it occurred for the first time today so I've switched to 60Hz hoping Apple will fix. It happened while watching a 4k HDR Netflix video (via Safari) for the first time if that's relevant.

This time I got a photo and panic log, signature is:

DCPEXT2 PANIC - apt firmware: dual_pipe.c:295 sync_pipe_end_of_config() -- - iomfb_mailbox(52)

apt firmware: dual_pipe.c:295 sync_pipe_end_of_config() --

RTKit: RTKit-3255.100.143.release - Client: AppleDCP-1041.100.97~429-t604xdcp.RELEASE

I have sent all these details through to Apple Support who will escalate to engineering.

Is anybody else getting this issue with the latest 26.4 Studio Display XDR firmware?

Reply

Answer 14

May 6, 2026 5:38 AM in response to jamesgbeaumont

It's happened for the second time on my new Studio Display XDR unit (which was a replacement for this issue occurring on my original unit).

Timeline:

10th April - received the unit

21st April - issue occurs for the first time

6th May - issue occurs for the second time.

I run pretty much the same set of applications every day. Only other thing I can thing of to mention is I also have 2 first-gen Studio Displays - all 3 monitors are connected independently to the Mac Studio, no daisychaining.

Reply

Answer 15

Krist3nz

Level 1

14 points

May 21, 2026 7:22 AM in response to amarjeetr

I’m seeing the exact same issue on my side with a similar panic signature, even after updating to the latest firmware/macOS versions.

My setup:

MacBook Pro M5 Pro (26.4.1)
Studio Display XDR (firmware 26.4)

The panic is still:

DCPEXT0/1 PANIC - dual_pipe.c sync_pipe_end_of_config()

Is there any updates from Apple or any improvement since posting this?

Reply