10+ years for a real BR2032, some months for a CR2032.
Even if you have a recently installed BR2032, double check the voltage with a voltmeter/multimeter, you don't really know how much time the BR2032 was in storage. Disconnect the power cable from the PSU and carefully remove the battery and check the voltage - replace it whenever is below 3.00V. Doing this will completely reset the RTC SRAM after 5 minutes or so with the battery out of the battery holder and you will start with fresh RTC counters.
You should do it even if it's just to eliminate the RTC being the cause of the com.apple.driver.watchdog crashes - most of the time the RTC being stuck is the cause for com.apple.driver.watchdog KPs that happen right after the Mac Pro enters sleep (the 120s).
I'm in temporary housing at the moment so I won't be able to check the existing voltage any time soon. I will try to remove the battery to reset the clock in any case. I always have SLEEP set to "never", so I don't think that is related in my case...and I just put the BR2032 in last year...so its always possible that is the case and when I can check the voltage I will, but I also think that is not likely...and I think its not coincidental that this started happening since recently updating to 12.5.1. But I will look into the battery. thanks.
I have updated my MacPro 3,1 & 5,1 to 12.5.1 with no issues so far. The incremental update wouldn't "take" on my hackintosh so I used the full installer. I'm wondering if there will be another update to fix the problems people are having with this one.
Just had another KP, I was away from my desk again so I have no idea what caused it. It might be the screensaver, though the screensaver seems to work ok when I'm here. The other thing I'm questioning is Parallels, which I usually have running in the background with Windows10.
when I came back to the desk. the screen was black, computer light still on, no response to keyboard or mouse. When I hit the power button I didn't have to hold it down in order to turn off, one click shut off the computer immediately.
Regarding Boot up, this time I Used cmd-V to see the verbose screen, which goes too fast to read anyway. Main reason is because I read on the Monterey thread that people who have been having problems booting are somehow able to avoid the boot up problems by booting in verbose mode.
In case anyone can make sense out of it, here is KP report:
I will add that before today, I had my config.plist configured with boot-args completely removed. Today I added it back with "-v" (after the KP). When I look at nvram variables now I don't see anything other than "-v" in the boot args.
Before today I updated to 12.5.1, nothing else. Got KP. Then I cleared my NVRAM and loaded never-booted ROM and and after a day or so, another KP (report above). Now I changed my config.plist to use boo-args=-v" and we'll see what happens.
chunklist-security-epoch=0 -chunklist-no-rev2-dev — I link these together because they sound related, and they often show up in combination in random kernel panic reports. Apparently they have to do with EFI signatures.
Using an online signing server also provides better protection against rollback attacks than typical global signature approaches. In a global signing system, the security epoch could have rolled many times, but a system that has never seen the latest firmware won’t know this. For example, a computer that currently believes it’s in security epoch 1 accepts software from security epoch 2, even if the current actual security epoch is 5. With an Apple silicon online signing system, the signing server can reject creating signatures for software that’s in anything except the latest security epoch.
Additionally, if an attacker discovers a vulnerability after a security epoch change, they can’t simply pick up the vulnerable software from a previous epoch off system A and apply it to system B in order to attack it. The fact that the vulnerable software from an older epoch was personalized to system A helps prevent it from being transferable and thus being used to attack a system B. All these mechanisms work together to provide much stronger guarantees that attackers can’t purposely place vulnerable software on a Mac in order to circumvent the protections provided by the latest software. But a user that’s in possession of an administrator user name and password for the Mac can always choose the security policy that works best for their use cases.
12.5.1 was allegedly a rushed out update, along with an update for iOS...related to some kind of urgent security hole Apple found...I read that somewhere. Dunno...Something is Amiss, that's all I can say... Is apple now doing something that has broken OpenCore under some situations?
@tsialex@Dewdman42 I may have missed it but have you tried disabling the AVX/APFS patch?
The only minor issue I have been experiencing since updating to 12.5/.1 is with UVFSService (never seen or heard of it before) hogging the CPU until it is manually terminated. Occurs once and randomly after a fresh boot until the process is killed, not sure why.
You may be onto something. When I originally installed 12.5.1 (clean install), I kept AVXpel disabled as a precautionary measure. I haven't had any issues with that installation, but it turns out that I also never re-enabled the patch...
You may be onto something. When I originally installed 12.5.1 (clean install), I kept AVXpel disabled as a precautionary measure. I haven't had any issues with that installation, but it turns out that I also never re-enabled the patch...
The debug log shared by @tsialex references APFS as the first line item in the backtrace which triggered the KP. It also reminded me of the KPs I had when AVX/APFS issues first came to light in 12.3 which the patch/kext resolved without reinstallation. I then decided to disable the patch before updating to 12.5, to see if it was still needed, and it has been smooth sailing since without it.
You may be onto something. When I originally installed 12.5.1 (clean install), I kept AVXpel disabled as a precautionary measure. I haven't had any issues with that installation, but it turns out that I also never re-enabled the patch...
Are you saying that AVXpel may be no longer necessary with 12.5.1+? If so, would that refer to the 12.5.1 install process or to running 12.5.1 itself? My Activity Monitor doesn't seem to contain a UVFSService line. What would that mean?
You may be onto something. When I originally installed 12.5.1 (clean install), I kept AVXpel disabled as a precautionary measure. I haven't had any issues with that installation, but it turns out that I also never re-enabled the patch...
I accidentally worked for several days without a patch and without a kext (I turned off the patch, thinking that I turned on the kext). but when before the next editing I saw that I turned everything off, I turned on the patch just in case
I didn't find any change in performance at all.
I accidentally worked for several days without a patch and without a kext (I turned off the patch, thinking that I turned on the kext). but when before the next editing I saw that I turned everything off, I turned on the patch just in case
I didn't find any change in performance at all.
You may be onto something. When I originally installed 12.5.1 (clean install), I kept AVXpel disabled as a precautionary measure. I haven't had any issues with that installation, but it turns out that I also never re-enabled the patch...
I am going to disable the patch until we hear more from syncretic about it. Its possible that this binary has changed in 12.5.1 resulting in only a partial patch, or who knows what.. Its clear to me that every new OS update from Apple from here on out is going to require a discovery period to find out if and when AVX is problematic...and potentially updating patches or other hacks to work around it. I also was never using voice control, though I have some concerns about boot up issues without the patch, but since you are now running with out the patch...really WTF knows...we are just making blind guesses now.
