Didn’t you say earlier that you had a kernel panic when booted into safe mode? That would mean LaunchBar would not have been loaded, right?–but good luck on continued success.
Yep, you’re right. Forgot about that.
Perhaps I’ll never know what it was.
[edit] Actually, I just checked and LaunchBar runs fine in SafeMode. Works as normal. Since I use it all the time, if it hadn’t loaded on boot I would have run it from the Dock.
Updating the long running saga:
After deleting the odd rule in LaunchBar I went many days without a kernel panic, but then they started again. So, it wasn’t LaunchBar. I decided to go ballistic. Booted in to Recovery Mode, erased the boot drive, reinstalled Monterey and used Migration Assistant to restore from a CCC backup housed on a Samsung external SSD.
Note that my Logitech bluetooth mouse didn’t work in Recovery Mode. I was able to find in the back of a drawer an old Magic Mouse on which the touch feature no longer works. So, it was the equivalent of a one-button mouse without a scroll wheel. It did get me through Recovery Mode right to the end…
All went well until Migration Assistant got stuck doing nothing. After seven hours I bailed and let the machine boot up. Of course, nothing had been migrated so it was setting up as if a new machine. Once I got my account done I ran Migration Assistant again. This time it did well and transferred everything (well, almost everything) in less than two hours.
And then the nightmare began. The machine would boot into a blank desktop with no menu bar and a non-functioning dock. The only way to reboot the machine was via the power button. I eventually got a normal GUI, but then the kernel panics started with a vengeance:
Kernel-2022-07-03-001916.panic
Kernel-2022-07-04-043549.panic
Kernel-2022-07-04-063322.panic
Kernel-2022-07-04-093528.panic
Kernel-2022-07-04-093902.panic
Kernel-2022-07-04-101554.panic
Kernel-2022-07-04-101755.panic
Kernel-2022-07-04-133957.panic
Kernel-2022-07-05-004738.panic
Kernel-2022-07-05-014549.panic
Here in Thailand it is now July 6th at 5:45 AM. I haven’t had a panic since the pair early morning yesterday. But that’s how it goes. Sometimes several in a few hours and then a week or more without one.
I’d forgotten what a hassle it can be to set up a new machine; even with Migration Assistant. MacPorts had to be reinstalled along with every requested port (via a handy script). Many applications are asking for Security & Privacy permission (that doesn’t get migrated) and some are wanting their registration key again.
Onward.
For what it’s worth, I’ve just done a little digging on the details of the kernel panic in the original post.
The output there includes mp_kdp_enter() timed-out on cpu 0, NMI-ing.
I believe that message is generated by line 1732 (or 1734) in the mp_kdp_enter function, in the file mp.c, for which the macOS 12.4 source code is available here: xnu/mp.c at e7776783b89a353188416a9a346c6cdb4928faad · apple-oss-distributions/xnu · GitHub
I believe that “KDP” in mp_kdp_enter is the Kernel Debugging Protocol. There is some information here: An overview of macOS kernel debugging
I haven’t read that document carefully. It does seem to be saying that turning on kernel debugging involves jumping through various hoops, depending on the particular method used.
If I do have the right end of the stick here, I wonder why the machine is trying to enter the kernel debugger in the first place. Do you have SIP turned off? Perhaps you have an app installed which is gathering low level information? (I wonder if iStat Menus uses kernel debugging.)
I have a fairly disruptive suggestion to try and isolate the cause… but it sounds like things are pretty disrupted already, so if you can tolerate it, worth considering? I’d try: reset the NVRAM (just in case: the document above mentions some values being set in there to enable kernel debugging), wipe the machine again, install an OS, don’t plug in an external drive, don’t migrate any data or install any apps. Do some basic testing of the machine for a while. With luck, the machine won’t give kernel panics. Given your list of frequent kernel panics above, if the machine operates ok for 24 hours without a panic, that might be good enough to be a “probably ok” indication. If that’s the case, then start reintroducing software and hardware, slowly. When the panics start again - the thing you just changed is a likely cause.
3 Likes
@Ashley - Thank you for taking the time to write your analysis of the kernel panic log. I don’t understand some of it, but I will read on and learn something, for which I am also grateful.
Some comments:
• You might be interested to read the first answer to the question I posed in Ask Different here: How to Diagnose Too Many Kernel Panics
• I do not have SIP disabled.
• It appears that the .panic files contain mp_kdp_enter even with iStat Menus is not running:
mnewman$ grep -l mp_kdp_enter /Library/logs/DiagnosticReports/retired/*
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-03-001916.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-043549.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-063322.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-093528.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-093902.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-101554.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-101755.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-04-133957.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-05-004738.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-05-014549.panic
• Although I appreciate your disruptive suggestion, I fear it would be too disruptive for me. Since the panics began, the machine has gone as long as ten days without a panic. That means that as I introduce software and hardware I’d have to wait at least ten days to make sure the current reintroduction was not the culprit. So, plug in a hard drive. Wait ten days. Plug in another hard drive. Wait ten days. Install an application. Wait ten days. Install another application. Wait ten days. And so on.
I’ve already sort of done this with all peripherals (except mouse and keyboard) and all software (except Mail and Messages). I removed one peripheral at a time. If there was a panic, I knew it wasn’t that one. Same with software. I removed one app. If there was a panic, I knew that one wasn’t the cause.
I realize that your suggestion starts with a much cleaner slate and has better control of the process. I’m just no ready to devote that much time at the moment.
• I look at it this way: After a panic, it takes about 3 minutes for the machine to reboot. If there are only a half a dozen panics per day and if I’m actually at the machine for half of those, then I lose use of the machine for less than ten minutes a day. Anything that turns out to be more disruptive than that is probably not worth the trouble; especially given the dozens of hours I’ve already spent on what now feels like tilting at windmills.
Thanks again for taking the time and making the effort.
And then, later this morning, this happened:
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-06-092137.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-06-092236.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-06-093106.panic
/Library/logs/DiagnosticReports/retired/Kernel-2022-07-06-094100.panic
Four panics within the span of 20 minutes.
FWIW, at the time I was using Firefox and Netshade’s VPN.
In the past, I isolated Firefox and Netshade at the same time and still had panics, so I’m fairly certain it’s neither of them.
After yesterday morning firestorm of panics, I had a few more:
/Library/logs/DiagnosticReports/Kernel-2022-07-06-120235.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-06-163015.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-06-164819.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-06-170948.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-06-173740.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-06-174255.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-06-174453.panic
/Library/logs/DiagnosticReports/Kernel-2022-07-07-030916.panic
And not a single one since the one 15 hours ago.
I just don’t get it.
So, I didn’t have another panic until I rebooted the machine for another reason. And then, immediately after the reboot:
Kernel-2022-07-10-080308.panic
Kernel-2022-07-10-102819.panic
Kernel-2022-07-10-104012.panic
Kernel-2022-07-10-180539.panic
Kernel-2022-07-10-181003.panic
Kernel-2022-07-10-181324.panic
Kernel-2022-07-11-082212.panic
And none since then.
The Apple technicians here in Bruges took a long and hard look at the machine and couldn’t find anything wrong with the RAM modules. They performed a clean install (after asking me if they could), reinstalled Photoshop and tried the same large files again. It seems to work. No more crashes and kernel issues since then.
I don’t want to reinstall everything from the Time Machine copy as it might reintroduce the problem.
Problem is this will mean very long hours to reconfigure my iMac…
Fingers crossed.
Your situation seems to be quite different from mine as you identified a particular cause (Photoshop with large files). I’ve not been able to identify any particular situation that causes the panic on my machine. I have done extensive work isolating both hardware and software and have come up with zilch.
I’ve had two panics in the last two days; one when I was replying to a post in a forum using Safari and another when the machine was idle in the middle of the night.
I remember having the same kind of issue with a Mac Pro G5. Once in a while it hung up on me. A few months later the CPU died.
I was fantasizing that the 12.5 update might fix the issue.
The update reboot was at 2022-07-21 06:03:41
And then this:
Kernel-2022-07-21-060717.panic
Kernel-2022-07-21-061451.panic
So, two panics within about ten minutes of installing the update.
For the past 11 days it looks like this:
Kernel-2022-07-10-080308.panic
Kernel-2022-07-10-102819.panic
Kernel-2022-07-10-104012.panic
Kernel-2022-07-10-180539.panic
Kernel-2022-07-10-181003.panic
Kernel-2022-07-10-181324.panic
Kernel-2022-07-11-082212.panic
Kernel-2022-07-17-091640.panic
Kernel-2022-07-18-191907.panic
Kernel-2022-07-19-192355.panic
Kernel-2022-07-20-120110.panic
Kernel-2022-07-20-120405.panic
Kernel-2022-07-20-122308.panic
Kernel-2022-07-20-123242.panic
Kernel-2022-07-21-060717.panic
Kernel-2022-07-21-061451.panic
Oh, well.
Some days are better than others:
Kernel-2022-07-10-080308.panic
Kernel-2022-07-10-102819.panic
Kernel-2022-07-10-104012.panic
Kernel-2022-07-10-180539.panic
Kernel-2022-07-10-181003.panic
Kernel-2022-07-10-181324.panic
Kernel-2022-07-11-082212.panic
Kernel-2022-07-17-091640.panic
Kernel-2022-07-18-191907.panic
Kernel-2022-07-19-192355.panic
Kernel-2022-07-20-120110.panic
Kernel-2022-07-20-120405.panic
Kernel-2022-07-20-122308.panic
Kernel-2022-07-20-123242.panic
Kernel-2022-07-21-060717.panic
Kernel-2022-07-21-061451.panic
Kernel-2022-07-21-153512.panic
Kernel-2022-07-21-154924.panic
Kernel-2022-07-24-160629.panic
Kernel-2022-07-25-093755.panic
Kernel-2022-07-25-133514.panic
Kernel-2022-07-25-163109.panic
Kernel-2022-07-25-163529.panic
Kernel-2022-07-25-163758.panic
Kernel-2022-07-27-045730.panic
One thing I’ve noticed is that sometimes after a panic the Mac will reboot twice in quick succession. For example, this morning there was a reboot at 4:59 after the 4:57 panic. It rebooted again at 5:12, but there’s no panic report for the second boot. Also, the second boot is often somehow incomplete: There is no menu bar on the screen, the keyboard doesn’t work at first and iTerm seems to have lost both it’s scroll back buffer and bash’s command history. In these cases I reboot from the command line (provided I can get the keyboard working). Following the manual reboot, all is well: the menu bar is there, they keyboard works and iTerm has suddenly remembered the bash command history and the scroll back buffer goes back many days.
It’s all very odd.