MP 1,1-5,1 Mac Pro 4,1 to 5,1 dual CPU sleep panic when second CPU package is active

[peterpan76]

Hello,

I am looking for help diagnosing a repeatable sleep panic on a dual CPU Mac Pro 4,1 converted to 5,1.

Hardware:

Mac Pro Early 2009
Originally MacPro4,1, converted to MacPro5,1
Dual Xeon E5520 2.26 GHz
8 physical cores and 16 logical CPUs total
16 GB RAM
Sapphire RX 580 Nitro+ 8 GB
Boot ROM 144.0.0.0.0
Processor tray SMC 1.39f5

The most important diagnostic fact is that sleep worked correctly before the MacPro4,1 to MacPro5,1 firmware conversion.

The conversion was performed specifically to allow installation of newer macOS versions.

Immediately after the firmware conversion, while the Mac was still running an older macOS version, sleep stopped working.

The same failure has since been reproduced on Monterey and Sequoia, so the problem does not appear to be limited to one macOS release or to the current OCLP installation.

The failure occurs only when CPUs from both physical processor packages are enabled.

Test results:

cpus=4 works
cpus=8 works
cpus=12 fails
cpus=14 fails
cpus=16 fails

With cpus=8:

hw.packages = 1
hw.physicalcpu = 4
hw.logicalcpu = 8

Sleep and wake are stable.

With cpus=12 or more, the Mac panics while entering sleep.

The repeated panic contains:

Failure during sleep: 0x00000019
Failure while halting non boot CPUs
pmLock: waited too long, held by 8

The relevant backtrace includes:

AppleIntelCPUPowerManagement
_i386_pmExitHaltToOff
_acpi_sleep_kernel
AppleACPIPlatform
AppleACPICPU haltCPU
IOCPUSleepKernel

CPU topology analysis indicates that kernel logical CPU 8 is the first active logical CPU belonging to the second physical Xeon package.

Its APIC ID appears to be 16.

Tests already completed:

CPUFriend and CPUFriendDataProvider disabled with cpus=12
Result unchanged

PowerTimeoutKernelPanic enabled
Result unchanged

No custom ACPI tables
No ACPI patches
No CPUID emulation
No DummyPowerManagement
No AppleXcpmCfgLock
No AppleCpuPmCfgLock

The RX 580 is unlikely to be the original cause because sleep stopped working immediately after the firmware conversion, before the current hardware and software configuration was completed.

Current workaround:

cpus=8

This disables the second physical CPU package, but sleep and wake are stable.

My questions are:

1. Has anyone seen this exact sleep panic after converting a dual CPU Mac Pro 4,1 to 5,1?

2. Could this indicate a compatibility issue between the original dual Xeon E5520 processors, the 2009 dual CPU tray with SMC 1.39f5, and MacPro5,1 firmware?

3. Could the problem be related to APIC topology or AppleIntelCPUPowerManagement when the second CPU package becomes active?

4. Has anyone solved a similar issue by replacing the E5520 processors with Westmere CPUs such as X5675, X5680, or X5690?

5. Is there a safe diagnostic test that can distinguish between CPU compatibility, processor tray SMC, Boot ROM conversion, and ACPI or APIC causes?

I can provide a full panic log, CPU topology output, and sanitized OpenCore configuration if needed.

 

[tsialex]

1. Did you replace the BR2032 RTC battery? This is the first thing to look when sleep stops working. Always reset the RTC and the SMC after replacing it, never use a CR2032 - wrong chemistry for the temperature below the GPU heatsink and will fail in weeks.
2. With a correctly working RTC, did you tested sleep with High Sierra without OC/OCLP?
3. Did you run AHT/ASD? Get a clean bill of health before anything.

While no one else reported sleep issues with cross-flashed early-2009s that have dual CPU trays, Nehalem processors are supported only up to High Sierra, with Mojave and newer things go awry with the dual CPU Mac Pros.

First failure people notice with cross-flashed early-2009s with dual CPU trays still with Nehalem Xeons when running Mojave and newer is the stuttering audio which can only be solved upgrading to Westmere Xeons.

 

[peterpan76]

1. Did you replace the BR2032 RTC battery? This is the first thing to look when sleep stops working. Always reset the RTC and the SMC after replacing it, never use a CR2032 - wrong chemistry for the temperature below the GPU heatsink and will fail in weeks.
2. With a correctly working RTC, did you tested sleep with High Sierra without OC/OCLP?
3. Did you run AHT/ASD? Get a clean bill of health before anything.

While no one else reported sleep issues with cross-flashed early-2009s that have dual CPU trays, Nehalem processors are supported only up to High Sierra, with Mojave and newer things go awry with the dual CPU Mac Pros.

First failure people notice with cross-flashed early-2009s with dual CPU trays still with Nehalem Xeons when running Mojave and newer is the stuttering audio which can only be solved upgrading to Westmere Xeons.

The Panasonic BR2032 battery has now been replaced.

The RTC and SMC were reset by leaving the Mac fully disconnected from power with the battery removed.

The Mac booted correctly with the existing cpus=8 workaround.

Sleep and wake were tested again with cpus=8 and both worked correctly.

The next steps will be AHT or ASD, followed by a native High Sierra test without OpenCore or OCLP and with both CPU packages active.

 

[peterpan76]

@tsialex, thank you for your guidance. I completed several additional tests.

I replaced the RTC battery with a Panasonic BR2032 and reset both the RTC and SMC. After the replacement, the system clock and firmware settings remained correct. Sleep and wake are fully stable with cpus=8, which activates only one physical CPU package.

I also ran Apple Hardware Test 3A207. AHT detected one defective 2 GB RAM module. I confirmed the fault by moving that module to a known good slot, where the error followed the module. The defective module was then removed.

The remaining 14 GB of ECC RAM subsequently passed the full extended AHT with no errors. This confirms that the defective RAM module was a separate fault and was not the cause of the sleep problem.

I repeated the sleep tests with both CPU packages active after removing the defective RAM:

1. During the first test, the Mac entered full sleep but completely froze during wake. There was no video output, no USB response, no disk activity, and no response to a short press of the power button.
2. During the second test, the Mac did not complete the transition into sleep.

After restoring cpus=8, sleep and wake are again fully stable.

Processor tray identification:

630-9402
Serial number begins with J5917, indicating approximately week 17 of 2009
Tray SMC: 1.39f5
Probable board number: 820-2336-A

Considering that the remaining RAM passed the extended AHT and the issue still occurs only when the second Nehalem CPU package is active, would you recommend performing the native High Sierra test without OpenCore or OCLP, or would it be more reasonable to proceed directly with a Westmere CPU upgrade, for example a pair of X5675 processors?

The graphics cards have already been swapped dozens of times during several days of testing. I would now prefer to avoid any further unnecessary replacements because I am concerned about damaging the RX 580 and, especially, mechanically wearing or damaging the PCIe slot. The RX 580 also does not slide into the slot as smoothly as the original ATI card because it does not use the same dedicated guide tray.

 

[tsialex]

No one ever reported your issue with 16 cores and sleep, so, you have something going on with your hardware or software.

My advice to test with High Sierra without OC/OCLP stands, you should be absolutely sure that your hardware is working perfectly before progressing with your tests or buying anything, besides that you have a very early made CPU tray that probably will have issues with 95W+ Westmere Xeons and maybe you gonna need a newer made CPU tray (Rev.B). Deep reset the NVRAM before running High Sierra to fully remove OC/OCLP NVRAM entries.

Also try to run AST ASD EFI.

 

[peterpan76]

No one ever reported your issue with 16 cores and sleep, so, you have something going on with your hardware or software.

My advice to test with High Sierra without OC/OCLP stands, you should be absolutely sure that your hardware is working perfectly before progressing with your tests or buying anything, besides that you have a very early made CPU tray that probably will have issues with 95W+ Westmere Xeons and maybe you gonna need a newer made CPU tray (Rev.B). Deep reset the NVRAM before running High Sierra to fully remove OC/OCLP NVRAM entries.

Also try to run AST EFI.

Thank you. Just to make sure I understand your recommendation correctly, by AST EFI do you mean the Apple Service Toolkit EFI Full System Diagnostic normally available through Apple or an authorized service environment?

Is AST EFI still available for an Early 2009 dual CPU Mac Pro, and can it be run independently by an end user, or would I need an Apple Authorized Service Provider with access to Apple’s diagnostic servers?

I have already completed Apple Hardware Test 3A207, including the full extended test. After removing the confirmed defective RAM module, the remaining 14 GB passed without errors.

If AST EFI is no longer available for this model, would ASD 3S132 EFI be the appropriate local substitute?

 

[tsialex]

Sorry, typo on my part. You need ASD 3S149 since is a cross-flashed early-2009 - you can't get access to AST without having GSK access:

Video Card Recommendation for Mac Pro 5,1 in 2024

Yes, Apple Hardware Test - AHT. Apple Hardware Test/Apple Service Diagnostics - AHT/ASD: You need to run AHT and to be sure that you don't have any hardware issues. You'll need an Apple OEM GPU with 64bit EFI (HD 2600XT, 8800GT, Quadro FX 5600, GT120, HD 4870/5770/5870) to run AHT/ASD. While...

forums.macrumors.com

You probably can get ASD 3S149 from macintoshgarden and etc.

 

[bongo_x]

I am having an almost identical problem, with almost the same machine. I had 72G of RAM and found one stick was bad and was sure that was the problem finally solved, but no. I have 3.45 speed CPUs, otherwise the same, just got the same video card thinking it might be the problem and needed a new one anyway.

I'm not as sure as you of the details, but the computer locks up overnight while in sleep. It worked fine for years, but started doing this a couple months ago in MacOS 10.14, continued in MacOS 12 with OCLP, through removing the bad RAM, changing of some PCI cards, video card, and even in FreeBSD.

No other problems.

 

[tsialex]

I am having an almost identical problem, with almost the same machine. I had 72G of RAM and found one stick was bad and was sure that was the problem finally solved, but no. I have 3.45 speed CPUs, otherwise the same, just got the same video card thinking it might be the problem and needed a new one anyway.

I'm not as sure as you of the details, but the computer locks up overnight while in sleep. It worked fine for years, but started doing this a couple months ago in MacOS 10.14, continued in MacOS 12 with OCLP, through removing the bad RAM, changing of some PCI cards, video card, and even in FreeBSD.

No other problems.

Check the BR2032 RTC battery voltage, run ASD.

 

[bongo_x]

Thanks, I did check the voltage and it says it's good (3.18?), I may have replaced it a while back? I even tried putting a CR3032 in there temporarily because I had one, but it didn't make a difference.

I tried running AHT(?) but it wouldn't work because I don't have an original video card. I think.

 

[tsialex]

Thanks, I did check the voltage and it says it's good (3.18?), I may have replaced it a while back? I even tried putting a CR3032 in there temporarily because I had one, but it didn't make a difference.

I tried running AHT(?) but it wouldn't work because I don't have an original video card. I think.

Yes, you need an AppleOEM GPU, get one.