iMac crashing during sleep - CATErr MCA data not found, working fine otherwise - possible solution!

Want to know more about what's going on?

If you know what time the Mac rebooted you can scour logs, but I'd open Console, select the "Mac analytics data" and search for "sleepwake.failure"

In my case a driver failed to load (unspecified) and caused the crash. I found that by looking at the time the machine crashed, but now I know a helpful error code, you can just search for it.

Now, want to monitor those sleep/wake cycles? Still got terminal open?

pmset -g log

What you're looking for is along these lines, around the time your Mac crashed:

2022-10-15 21:30:46 +0100 ShutdownCause       	SMC shutdown cause: -128:                                                  	          
2022-10-15 21:30:47 +0100 HibernateStats      	hibmode=0 standbydelaylow=0 standbydelayhigh=0                             	          0         	
Sleep/Wakes since boot at 2022-10-15 13:24:47 +0100 :0   Dark Wake Count in this sleep cycle:73

Time stamp                Domain              	Message                                                                    	Duration  	Delay     
==========                ======              	=======                                                                    	========  	=====     
UUID: Unknown UUID
2022-10-15 21:30:47 +0100 Failure             	Failure during sleep: 0x00000014 : Some drivers failed to handle setPowerState	          
Sleep/Wakes since boot at 2022-10-15 13:24:47 +0100 :0   Dark Wake Count in this sleep cycle:73

That Dark Wake count is normally in single digits overnight when the machine is behaving; in this case I'd been running Cubase, Civ VI, anything I could lay my hands on to keep the machine from sleeping/try and make it crash.

Final tips:

• Leave a terminal window open. if your Mac opens apps when it logs in. It'll show every time the machine has rebooted at a glance.
• When diagnosing a sleep issue, connect a wired mouse and keyboard. This will allow you to disable bluetooth. A wireless mouse and keyboard with a dongle should be okay IF the dongle is known to work and behave, but jittery connections/false inputs might cause more problems or distract from the actual issue.
• If you know the computer's suffering the rapid sleep/wake cycles, don't waste time waiting for it to crash. it might still have a problem, but you can eliminate the sleep/wake side of it while you're using terminal.

1. 1. Run the pmset and log searches above and verify that you're still getting the rapid cycle.
   2. Change your connected devices (such as dock, drives, controllers) and then sleep the computer from the menu.
   3. Go make a cup of tea, leave it five minutes or so; if you've got a controller/device that has a USB activity light (in my case, the green Thunderbolt active light on my OWC dock) you'll see them sleep, then wake as the computer tries a Dark Wake it seems, then sleep and stay asleep.
   4. If they wake up in that five minutes there's probably something wrong.

After five minutes, wake the computer, check the logs in terminal, and if there isn't a string of wake reasons while you were away, then enjoy your cup of tea, reboot the computer, and keep a sideways eye on it for the next few days, maybe manually sleep it and see if it reboots; mine seemed to be every three hours by the time the drivers fell over themselves and the machine fell over, but that was partly affected by Mac OS background tasks that prevent sleep.

It works fine - but what's it proving vs. checking the logs/monitoring sleep and wake performance? I'd already seen posts suggesting disabling power nap/etc. settings and they made no difference to a machine going into energy saving sleep or being asked to manually sleep subsequently being woken by a half-asserted driver?

Did you read the whole post or just reply to the i initial premise around the CATErr: kernel panic and wakes from sleep? The whole point of the post is that I found countless bits of advice like this - and for the proper functioning of the Mac, disabling sleep and power nap isn't a fix for the problem.

I traced the problem on my machine and posted the solution and explanation, a thing that is woefully lacking on these support forums. It was nothing to do with settings, it was a faulty USB driver loaded at a low level - something easily done (particularly as it's an optical drive that loads of people might use instead of an Apple one) and the whole point was to restore the proper operation of the Mac.

Nearly all advice around Kernel Panics is "remove all the devices". You'll never solve this that way.

If you have a previously working machine with this CATErr log with MCA data not found from a crash, boot it normally and plug every device you have into it, making sure it shows up in system profiler - then remove it. It's the only way to know the driver has been fully loaded, and thus, can be fully unloaded when the device is removed.

What is XHC2 XHC1 in MacOS logs?

So in my case it's XHC2 XHC1. that is waking the computer.

You'll see that a lot when you search for this problem - in the iMac 18,3 it's what the PCI bus uses to identify USB devices making a power request, and it is attached to the Thunderbolt chipset but, not necessarily the Thunderbolt port, because USB is delightful.

You'll see plenty of answers here saying "it was a trackball" or "it's your USB Device" even if the logs show no such data, because people have decided that XHC must be the HID devices - particularly as sometimes, you'll see the HID device referenced alongside the XHC identifier.

However, although it's not a bad place to start looking, you cannot say 'it's a USB HID' device, or 'it was my mouse' or 'it was bluetooth' unless there's further driver or device info given.

XHC2 and XHC1 are part of the ACPI power management device tree and appear to be purely "USB Device via PCI, through Intel Thunderbolt chipset (which is also USB-C)".. Perhaps someone with better technical knowledge can explain how the devices relate to each other, but this is a good start and a good site for diagnostics:

https://eclecticlight.co/2017/08/08/sleep-wake-and-startup-hardware-and-acpi/

Guess what, my bluetooth keyboard goes to a bluetooth adaptor inside the Mac via USB, and it asserts a wakeup command via this chipset.

Why did the issue persist through power cycles and OS updates?

I haven't got a clue, to be honest. I think, my best-guess, is that the Samsung (MediaTek) optical drive registers as a spoofed SCSI device on the USB tree - whether that is a Mac thing, or it'd show on a PC in the same way, it seems like the sort of device that would be needed BEFORE an OS is loaded, so part of the EFI platform configuration, Maybe an incomplete driver loaded into EFI, maybe a stub for a nonexistent device, I'm guessing wildly.

So this probably affects any device that might be wanted before the OS loads - mass storage devices, displayport/USB docks and hubs, and mass storage devices and storage device controllers If they make the system think it has hardware present that isn't actually there, it could lead to the conclusion the logic board is broken.

Either way, it seems like Apple could help users a lot by including a 'Reset EFI and machine configuration' option in Recovery mode, as resetting NVRAM and attempting to reset the SMC (in my case, the 15 seconds or more without power was while removing and reseating all the RAM because of all the posts saying 'logic board' or 'bad RAM') had no effect.

This is just one 'solution' out of thousands of potential problems, so I'm not saying it'll fix your machine. But it's worth a shot before you take a cursed Mac to a Genius Bar, it passes hardware diagnostic, survives a reinstall/recovery, but still keeps crashing in sleep leading them to conclude it needs a logic board. If you do all this for this issue, and it still does it, it probably does need one.

Yeah, I wasn't going for a workaround, and I was aiming at helping users with a specific sleep related issue (crashing during sleep with an unhelpful KP report), not all sleep related issues. Providing solutions to generic sleep related issues in a thread about a specific one, when you've provided that answer countless times in other sleep related issues threads, seems redundant.

You've clearly been around here a while - so putting aside the cut 'n' paste reply, do you have any technical knowledge about this issue and how Macs handle device drivers between EFI and OS, because that would be genuinely helpful in terms of narrowing down what classes of USB (or related) device can cause this situation.

For example, the MediaTek/Samsung optical drive I have would often not work on the iMac 14,2, but it didn't cause this behaviour. On that Mac under Catalina, you could plug it in and use it, but then next time - after a restart, or sleep - you'd need to unplug it and plug it back in. It would be there and have power, but it just wouldn't respond. On the iMac 18,3 it was plugged in when I powered the machine up, but never showed up so I missed that it was there (it'd on a long USB cable to a hub for some MIDI synths and usually gets switched off with the hub power switches). Whatever the bug with it was on the 14,2, on the newer machine it created something in firmware that was trying to find the device over USB as far as I can tell - like, say, a virtual SCSI device, but not the DVD device it then refers to:

Please read the whole thread and understand what the problem with the system was, how it manifested, and what the actual fix was? The point being that for most users they'll try the safe boot etc. and because the issue is a step below there, the problem remains. It persisted through safe boot, reinstall OS and two OS updates.

I got sick of finding non-answers to CATErr: MCA data not found kernel panics - because MCA data not found IS inherently a non-answer, the machine's crashed with a hardware error for a phantom hardware device that doesn't exist, but it's crashed because it's being asked to sleep/wake repeatedly and the drivers etc. just cannot keep up.

Disabling sleep may alleviate the problem, but it doesn't fix it, and the idea that there's a hardware fault and a potential logic board replacement needed persists as a result. Ten days of not being able to let this go lead me to finding the actual solution and yes, it's been reported to Apple - I'm running Ventura now as I updated to 12.6.1 and to 13 to see if they would update the firmware, and unlike the M1 Macs or older Macs, there's no easy way to update/replace the firmware on Kaby Lake machines.

but the things is, what will Apple do with the report? It affects older Intel machines - as far as I can tell MCA reporting like this (earlier versions exist, but don't seem to report in the same way) exists from Haswell onwards with Thunderbolt 2, so post-2014 Intel Macs can potentially report this, other eras may crash differently regardless of OS. I suspect the rule is 'if it supports Big Sur, it can potentially crash this way from a malformed peripheral referenced by EFI'. My iMac 14,2 has Thunderbolt 1.

That doesn't mean someone who has persistent wakes because an optical trackball is vibrating or a USB cable is falling out of a hub somewhere won't get a very similar problem - but those ones will probably be alleviated by removing the offending device.

Now, is the potential for this crash related to the error reporting? Obviously not. But... it does seem like there was a change in how EFI behaves pre-boot, perhaps related to enhanced system security, that meant that finding the problem was difficult.

To clarify the XHC1 issue further I took a look at my iMac 14,2 in IOJones - EVERY USB DEVICE - disks, everything, including onboard bluetooth - is under that tree in the IOPower set (ACPI). Any wake from sleep, dark or otherwise, initiated by a USB device is going to be XHC1 on this machine, and XHC2 XHC1 on the Mac 18,3 and other machines with the same chipset (TB3/USB-C).

Step one for gathering that information is surely to read the post fully before responding to it? As far as I can tell looking at this community the approach seems to be to look at the topic and cut & paste a standard response before even looking at what the user has said about their problem or system. Might get helpful

votes; helps few people. Most of the threads around CATErr: MCA data not found kernel panics state the system, OS and include the offending panic log (hence why I found them

when looking for answers), and end with no solution.

I would have posted this diagnostic and successful fix on those questions but that's resurrecting very old threads. The thing is, these forums remain visible and searchable so if every thread around unrelated but similar issues ends with the same blanket advice (cruise control

not working on your car? You explained how the throttle, brakes and pedals feel during this? Never mind, just disable cruise control) it simply perpetuates the idea that these issues are long-term, unfixable and "a mystery".