Kernel Panic With 4k 240 Hz External Monitor

We already provided a reasonable way to reproduce the issue. It’s not our job to try to find an even easier way, and I doubt it would make any difference anyway. Considering the amount of people that could reproduce this issue, I find it very hard to believe that only Apple cannot, *if* they tried with an actual 240Hz monitor. But even if they cannot reproduce the issue for whatever reason, they also have the crash dump. That might be sufficient in itself to debug the issue. But regardless, they didn’t say any specifics on why they couldn’t reproduce the issue, and they didn’t ask for any additional information either. It’s not possible to make any progress if Apple doesn’t want to communicate what is blocking them, so we could help them in a meaningful way. Expecting users to try to guess what they would need is unreasonable. At least, I’m not interested in that.

There’s no other known way to avoid the crash, so everyone should do that, until a fix will be implemented. But this is just a workaround, and kernel panics shouldn’t be left unfixed. Or if Apple doesn’t want to fix this, then they should disable 240Hz support. This is not “just” an annoyance, it might even be a security issue.

If you do not have a recent local, disk-based backup, your computer is like a ticking Time bomb. You are only one disk failure, one crazy software, or one "oops" away from losing EVERYTHING! Drives do not last forever. It is not a question of IF it will fail, only WHEN it will fail. In addition, you never know when crazy software or Pilot Error throws away far more than you intended.

If you are using another direct-to-disk backup method that you prefer, and you currently have a recent disk-based backup, that is great. If not, you should consider using Built-in Time Machine. Take steps to acquire an external drive as soon as possible. If you buy one, a drive 2 to 3 times or larger than your boot drive is preferable for long term trouble-free operation. Do not pay extra for a drive that is fast.  (You can get by for a while with a "found" smaller drive if necessary, but it will eventually become annoying).

Attach your external drive and use

System preferences > Time machine ...

... to turn on Time Machine and specify what drive to store your Backups on.  It may ask to initialize the new drive, and that is as expected. APFS format is default format if running MacOS 11 Big Sur or later.

Time machine works quietly and automatically in the background, without interrupting your regular work, and only saves the incremental changes (after the first full backup). Time machine backs up every connected drive that is in a Mac compatible format. it can not back up Windows format drives.

Time Machine's "claim to fame" is that it is the backup that gets done. It does not ruin performance of the rest of the computer while doing its backup operations. You do not have to set aside a "Special Time" when you only do backups. When you need it, your Time machine Backup is much more likely to be there.

How to use Time Machine to Backup or Restore your Mac:

Back up your Mac with Time Machine - Apple Support

that looks like a 4k display with

• 1x DP 1.4 (HDCP 1.4 & 2.3)(Supports up to 3840 x 2160 240 Hz, DSC, HDR)
• 2 x HDMI 2.1 (HDCP 1.4 & 2.3)(Supports up to 3840 x 2160 240 Hz FRL, HDR, VRR as per specified in HDMI 2.1) (including 1x HDMI 2.1 FRL with eARC - to support Dolby ATMOS signal pass-through)

what interface(s) are you using? how long are your cables?

based on your having:

"M2 Max MacBook Pro"

... it should be massively LOAFING running that display with either of those setups.

Your panic appears to be some sort of Display Co-Processor (DCP) Panic, but I don't see much there to gloom onto.

How about an Etrecheck report?

Consider downloading and running this little "discovery" utility, Etrecheck. It changes NOTHING. Etrecheck was developed by senior contributor here, and uses system calls to collect often-needed information.

it contains little tests for speeds of devices, CPU utilization, memory usage, energy usage and a digest of recent problems, in one easy to use package. it does not even need to be Installed. Because less can be learned when your Mac is running great, best time to run is when your problems are actually occurring, if possible.

if you follow the directions faithfully, its report (pre-laundered of all personally-identifiable information) can be "Shared" to the System ClipBoard, then Pasted into an ‘Additional Text’ window in a reply on the forums.

Use Etrecheck Pro for free:

http://Etrecheck.com

then start a reply on the forums and use the additional text icon in the reply window footer, and PASTE the report

...

Unfortunately the issue is still present with macOS 15.3. I got a kernel panic in less than an hour. Disappointing...

The more users report this as an issue, the higher the priority to apply Engineering resources to investigate, and try to find a fix.

if VPN vendors stuck with doing VPN, using them they would be a modestly bad idea. But most VPN vendors also scan your files for Viruses, often intervening in your Internet activity to break into encrypted connections to be FIRST to scan your files, and leave it less secure to completely broken. VPN for any purpose by institutional network presence is just a bad idea.

pixelwave wrote:

As I wrote in my post.. that is the version I am on. So no …

The original poster is Infilak.

This is not your discussion thread, you are hijacking it.

You have no posted your etrecheck report, and all manner of things might be happening to your system alone.

themoodster wrote:

Have not seen a single crash since setting it to 120hz

That is quite unusual, because the portion of your Mac that is crashing (the display co-processor) is NOT involved in screen-redraw., and should not be impacted by changes in refresh rate.

Perhaps this is indeed a very complex co-processor interaction with high speed timing implications.

Once the image of the screen has been drawn/rendered into the display-buffer using the Display Co-processor, a Rasterizer/DisplayGenerator automaton re-sends a screenful of display data, every refresh interval. The display Co-processor does not need to be used unless/until the screen changes.

Because there is so much data in one screen, being sent so fast, handling of these data using the processor or co-processor alone is impossible, and can not be done that way.