Kernel Panic - MacBook Pro Apple M1 13 Inch

<< Fix appears to be checking the "Prevent computer from sleeping automatically when the display is off" in the Energy Saver panel of Preferences. >>

^-- So the above is the support-suggested work-around for kernel panics citing DART-related issues??

This occurs daily for me as well. Mac mini M1 OS 11.1. I am using HDMI to connect to 4K monitor.

Second MacBook Air M1 connected to Samsung 4K monitor via Hyperdrive USB-C Hub works a little better

Third MacBook Air M1 connected to Vizio 4K TV via HDMI through a OWC Thunderbolt 3 dock is the most reliable.

Other differences. Mac mini has bluetooth keyboard and magic mouse 2. Both Airs use Logitech trackballs and Logitech Wireless keyboard with USB dongle. I think there may be an issue with bluetooth wake, but it could be having an issue waking up because it crashed.

The daily crash happens when monitor goes to sleep. Support had me check "prevent computer from sleeping..." in energy preferences and we'll see what happens tomorrow.

M1 Macs are having massive problems with kernel panics while attempting to put thunderbolt devices to sleep via power management. Apple is receiving TONS of kernel panic logs but pretends they've never heard of the issue when called via tech support. It appears Apple is pretending the issue isn't real.

You can find instances all over the internet with people complaining about kernel panics and many thunderbolt devices (monitors, raid arrays, TB hard drives, thunderbolt docks, soft raid programs loaded onto external raid arrays, etc). People are also complaining about monitors connected via HDMI. Apple has a massive M1 problem on its hands and so far is pretending it doesn't exist.

Lots of people are returning their M1 Macs before the return window closes because they're not getting any sense that Apple is even acknowledging the problem.

WindowServer is the MacOS task in charge of drawing windows for you to see on your display. (No relation to Microsoft Windows). that is the thing that crashed. I am not user why.

If you get more like this one, you have a trend that can be tracked down and fixed.

If this is a non-trend (all over the map in different routines for different reasons) it is likely to be a festering RAM memory problem.

Is this consistently for the same panic reason? if so, you may have a hardware issue, and should seek service.

In this context, DART appear to stand for Device Address Resolution Table, a complex way to decide what I/O (i.e., not RAM) is being addressed, and finding its ring-buffers.

Hey, could your problem be related to Football Manager? Our reports are very similar

Check my thread and log: https://discussions.apple.com/thread/252210055

And also: https://community.sigames.com/forums/topic/544503-macbook-pro-m1-2020-shuts-down-while-playing-fm21/

Jan 7th 2020 Update, also on BeachStreetNews.com again:

Good News:

Mac Mini M1 16gb/1TB OS 11.1 BlueTooth Keyboard Magic Mouse 2 did not crash for the first time today. Fix appears to be checking the "Prevent computer from sleeping automatically when the display is off" in the Energy Saver panel of Preferences. This was at the request of Melissa in tech support. Not a great fix but a fix none the less so hopefully Apple addresses it.

Bad News:

MacBook Air M1 16Gb/1TB OS 11.1 did crash again today. There is a pdf of the crash log on the Beach Street News blog post. I can't figure out how to attach it here. This crash appears to be USB related. This MacBook Air is connected to a Thunderbolt 3 port replicator. That in turn has a 4k HDMI monitor, Logitech solar keyboard with USB dongle and Logitech track ball attached. This is the second crash on this MacBook Air M1.

The only problem free unit is the MacBook Air M1 8gb/512MB with Hyperdrive (indegogo beta version) port replicator, Samsung monitor, Logitech keyboard and trackball, G-Tech external drive. This one is used exclusively for email, photo editing on Adobe creative cloud and web surfing on safari.

At present, we have no known work-arounds for DART problems. It may take a mainboard swap to solve the issue. This is new custom silicon, and they may not be testing them thoroughly enough to weed out the ones that fail this way "after about hour of use."

They are NOT going to chase you down. If you have an issue, DO NOT wait for a software update, "Get Support" and work with them on a cause and some form of relief. Only they know the best form for that relief.

Get Support

I just wanted to give an update about my

personal experience. I’m now 99% sure that my kernel woes were related to one specific program I was running that wasn’t optimized for Apple’s M1 chip (Football Manager 20). I have had my MacBook Pro for 2 months now and haven’t encountered this issue in any other case, though I’m sure the issue is still a problem that Apple should be addressing.

After spending most of the afternoon researching and reading a wide variety of forum posts, it appears my external ORICO NVMe USB-C 3.1 (10Gbps) SSD enclosure shipped with Realtek RTL9210B-CG firmware that was not "Mac Friendly". I applied a firmware upgrade on a Windows PC and -- so far -- no issues observed through several sleep/wake cycles and lots of file copying tests. I'm optimistic this was the root cause of my spontaneous disk ejections & reboots. I'll update you in a few days.

Is this consistently for the same panic reason? if so, you may have a hardware issue, and should seek service.

In this context, DART appear to stand for Device Address Resolution Table, a complex way to decide what I/O (i.e., not RAM) is being addressed, and finding its ring-buffers.

When you have the same panic-reason over and over, that suggest you have a problem that can be tracked down and fixed.'' This one appears to be related to DART.

Be sure to send a printed panic report in when you submit your Mac for service.

When you have completely different panic reasons "all over the map" that suggests something far more complex or a RAM memory issue.

NB>> On these MacBook Pro models, you MUST have a Trusted Backup on hand. Your boot drive will NOT be returned to you if the mainboard is swapped out during service.

A bit of positive news. I held off for the past two weeks to be sure that the kernal crashing issue had really passed, which it now seems to have done. Just to refresh, my M1 MacBook Pro, with 16GB RAM, was crashing once a day, after even very light use (Safari, etc) and with no peripherals of any kind attached and Bluetooth either on or off.

After trying multiple things, I began to wonder if I had imported the problem with the migration of my Home Folder from my desktop (iMac), running Catalina to my Big Sur MacBook.

Therefore I went back through all of the User/Library folders and deleted everything that didn't seem absolutely necessary, from the entire contents of much of my Application Support folder to all the irrelevant prefs files in my Preferences folders. From the little I know on the subject, none of these should have been responsible for Kernel Panics in any circumstances, but I was going crazy trying to find the problem.

And it seems I have. Somewhere there the culprit must have been lurking. Because, even before I upgrade to Big Sur 11.2.1 (maybe tomorrow) the kernal crashing seems to have stopped and the MacBook is running perfectly. For those who, like myself a couple of weeks back, were close to giving up, it might be worth an hour or so with a feather duster clearing out any cobwebs that you didn't think could still be there, and maybe tripping you up.

As noted in my reply to seminolefans no crash today, only change was in energy saver preferences as noted in post.

Also getting daily/nightly kernel panic restarts on my M1 Mac Mini (base model). I'm thinking it's likely USB -driver related? I also have a Samsung 4K monitor (60Hz via HDMI-2 direct) and an ORICO 1TB NVMe external SSD. I initially tried the SSD via USB-C but it panicked nightly so I switched to USB-A cable and it still panics. No Google Chrome or hub installed here. I just keep seeing USB scattered throughout the kernel panic log so I'm suspicious that's the culprit.