MacOs Kernel Panic, Source not clear

paulfromhemmingen wrote:

Hi,

I migrated my old Mac to my new MBP (16,4, M1 Pro if that's relevant) a week ago and starting yesterday it kept crashing due to Kernel Panics. I am not sure what change I made / software I installed that led to this happening, but I would really not want to do a factory reset if there's another way, given how time intensive that would be. (There first panic happened a couple of seconds after I gave Alfred accessibility permission, but that might just be a coincidence)

No external peripheral were attached when the kernel panic happened.

I. have attached the crash report, in case anybody can make any sense of that. (Only a bit of it, since the complete report is more than 400k characters and wouldn't fit. I'm happy to upload it elsewhere, if that would be helpful)

<Panic Report.log>

Many thanks for your help!

Kernel Panics are predominately caused by hardware faults or faulty third-party kernel extensions.

Learn what to do if your computer restarts or shuts down unexpectedly, or you get a message that your computer restarted or shut down because of a problem.

If your Mac spontaneously restarts or displays a ... - Apple Support

https://support.apple.com/en-us/HT200553

The signature of that panic indicates a memory problem.

Run Apple Diagnostics to check the RAM. It may not necessarily be the RAM, though. It could be a problem with the comm between the RAM and Logic Board.

I would imagine the RAM is soldered onto the Logic Board, so it would require taking it to an Apple Store or Authorized Repair Center.

paulfromhemmingen wrote:

Thank you for your help. I uninstalled the Apps as suggested by the other reply, but just know the kernel had another panic, the log is attached. Does this confirm the suspicion that it's GPU related (hardware, or driver)?

I didn't buy directly from Apple (also outside 14 days), but might swing by the closest Apple Store and see what they can do.

<Another Kernel Panic Log.log>

Make an appointment for a "hardware issue"—

https://www.apple.com/retail/geniusbar/

Outside the USA

https://locate.apple.com/country

From iOS device using the "Apple Support.app” to make a online Genius Bar appointment is easy: 

https://itunes.apple.com/us/app/apple-support/id1130498044?mt=8

panic(cpu 5 caller 0xfffffe0024e44538): Spinlock[0xfffffe299a622040] timeout after 12606975 ticks; current state: 0x2247, start time: 206117468927, now: 206130075902, timeout: 12582912 @locks.c:723

Spinlock timeout. A spinlock is where one CPU is spinning in a tight lookup checking a lock bit, while another thread running on another CPU owns the lock, and when it finishes using the lock data structure, it is suppose to clear the lock, at which time the spinning CPU will grab it.

Spinlocks are suppose to be for very fast locking activities, where the data structure being locks will be modified, quickly and the lock released.

In this case the thread that took the spinlock, did not unlock it quickly. Eventually the CPU spinning on the lock, incremented a counter to a value sufficiently large that it decided the lock was never going to be unlocked, and triggered a kernel panic.

Yes, this is again in the graphic drivers. But in a different place

Kernel Extensions in backtrace:

 com.apple.iokit.IOGPUFamily
    dependency: com.apple.driver.AppleMobileFileIntegrity
    dependency: com.apple.iokit.IOGraphicsFamily
    dependency: com.apple.iokit.IOPCIFamily
    dependency: com.apple.iokit.IOReportFamily
    dependency: com.apple.iokit.IOSurface
 com.apple.AGXG13X
    dependency: com.apple.driver.AppleARMPlatform
    dependency: com.apple.driver.AppleMobileFileIntegrity
    dependency: com.apple.driver.RTBuddy
    dependency: com.apple.iokit.CoreAnalyticsFamily
    dependency: com.apple.iokit.IOGPUFamily
    dependency: com.apple.iokit.IOReportFamily
    dependency: com.apple.iokit.IOSurface
    dependency: com.apple.kec.Libm

It could still be software, but I am currently leaning towards hardware. There are some very strict rules about using spinlocks among kernel programmers, and taking a long lunch is not one of them.

This could be a memory failure, as well as GPU, or CPU failure. In the case of memory, if the thread holding the lock actually unlocked, it but the bit change did not take effect, or the cache was not invalidated so other CPU's could see the change, or lots of other reasons that bit change was not seen by the CPU spinning on the lock, so it timed out.

Again, I'm just leaning towards hardware. I do not have nearly enough M1 Pro experience to make a strong claim.

Apple's return policy during Christmas is anything purchased after November 1st until Christmas, can be return before January 8th, 2022.

https://www.apple.com/shop/help/returns_refund

Post the EtreCheck.

That panic is mis-wrapped (\n\t\t should be a newline and two tabs), and panics tend not to be all that useful outside of Apple.

I don’t see any add-on kexts, but I’m not entirely certain of that given the wrapping.

Bad hardware, bad memory, problems on the USB or Thunderbolt, or bad kexts, are the usual causes.

If there’s any add-on cleaner apps, add-on anti-malware apps, add-on VPN apps, add-on firewall apps, or other similar apps, remove all of those per the vendors’ instructions, restart, and see if the panics persist.

Clean off the external USB and Thunderbolt, and see if the panic continues.

That Cisco AnyConnect looks old, as 4.10.4071 seems the current 4.10 patch.

I’d remove that AlDente Pro app, the AppCleaner app, and the SurfShark app. (SurfShark has also crashed.)

Apps that “assist” or change the behavior of macOS are common suspects when problems and panics arise.

I’d get Time Machine configured and going.

Clear off the three apps per the vendors’ instructions, clear off all externally-connected devices as a test, and see if the panics persist.

Returning this Mac is your decision.

Hi, thank you for the suggestion! Apple Diagnostics came back with no error, not sure if it's just unable to diagnose the error, or if its on the software side.

None of your third-party kernel extensions were loaded at the time of the panic, so they couldn't have caused the panic.

Did you buy it directly from Apple within 14 days? If so, I would return it no questions asked.

The GPU is listed in the dependencies, so it could be related to a faulty GPU.

If it has been more than 14 days, you'll have to contact AppleCare.

"panicString" : "panic(cpu 2 caller 0xfffffe002bc2f9e0): [data.kalloc.16]: 
element modified after free (off:0, val:0x0000000000002247, sz:16, ptr:0xfffffe300051cd70) 0: 0x0000000000002247

Modifying allocated memory after a thread has freed it, is a no-no in both the kernel and user space. It generally means the code's Left hand was not paying attention to what the Right hand was doing. It could also be a multi-threading issue where locks should have been used, but were not.

There are zero 3rd party kernel extensions, so this is all Apple code.

As this is M1 code, it is possible this is an Apple bug in M1 specific kernel code, which is new and hasn't existed long enough to get all the bugs out yet.

Here is the backtrace

Kernel Extensions in backtrace:
 com.apple.iokit.IOGPUFamily
    dependency: com.apple.driver.AppleMobileFileIntegrity
    dependency: com.apple.iokit.IOGraphicsFamily
    dependency: com.apple.iokit.IOPCIFamily
    dependency: com.apple.iokit.IOReportFamily
    dependency: com.apple.iokit.IOSurface

This implies the panic happened in the graphics drivers. Again, since this is the M1 Pro chip, and the GPUs are relatively new to macOS, it is possible this code needs a little more work.

Or it is possible that this chip should have been "Binned" to a 14 core GPU, and maybe one of the GPU cores is not behaving up to spec.

Use the Get Support in the upper right of this webpage, and discuss your options with Apple Support. Reports that using chat seems to be the fastest option, though with the holidays who knows?