Dual-CPU X99 Hackintosh Update: High Sierra, Clover r5123, and What to Watch For

If you maintain a dual-CPU Hackintosh on X79 or X99, you already know that updating the system — whether it's a macOS point release, a bootloader version, or a kext set — carries more risk than on a single-socket build. The inter-CPU QPI/UPI links, the NUMA topology, and the ACPI tables (SSDTs for processor objects, system locality information table, and multiple APIC entries) all interact with the OS kernel in ways that single-CPU configurations never exercise. I recently performed a structured update on an X99 dual-E5 v3 workstation running macOS High Sierra 10.13.6 (17G14042) with Clover r5123, and this article documents the exact steps, the pitfalls encountered, and the validation checks that confirmed stability afterward.

Why Update a Dual-CPU System?

The primary reason to update a dual-CPU Hackintosh is not chasing new features — it's maintaining compatibility with security patches and keeping the bootloader aligned with evolving ACPI handling. Apple's kernel has subtle differences in how it enumerates CPUs across physical packages. Clover and OpenCore both introduced changes between 2020 and 2023 that affect how _OSI queries, XCPM (XNU CPU Power Management), and Lapic kernel patches are applied. If you stay on an old bootloader, you miss critical fixes for kernel panics on systems with more than 16 logical cores. Additionally, some later versions of Lilu and WhateverGreen require a minimum bootloader revision to function correctly on multi-socket hardware.

Before starting, I recommend reading the broader overview of multi-CPU pitfalls in our earlier post Dual-CPU Hackintosh: What Works, What Doesn't, and Why You Should Think Twice. That article explains why certain Xeon steppings and chipset revisions cause boot failures — context that directly informed the update sequence below.

System Baseline Before Update

• Motherboard: ASUS X99-E WS (BIOS 4101, modified with UEFI GOP for the GPU)
• CPUs: 2× Intel Xeon E5-2697 v3 (14 cores / 28 threads each, total 28 cores / 56 threads)
• RAM: 128 GB (8×16 GB DDR4-2133 ECC RDIMMs, quad-channel per socket)
• GPU: Sapphire Radeon RX 580 8 GB (Polaris, natively supported up to Monterey)
• Bootloader: Clover r5099 (previous version)
• macOS: High Sierra 10.13.6 (17G14042) with Security Update 2020-006
• Kexts: Lilu 1.5.9, WhateverGreen 1.5.9, AppleALC 1.6.9, FakeSMC (v6.26-545-g8f5e3f3), NullCPUPowerManagement (required for dual-socket X99), X79PlatformPlugin injector (custom)
• ACPI: Custom SSDT for CPU0/CPU1 (SSDT-PR00 and SSDT-PR01), SSDT-UNC (uncore frequency), and patched DSDT with _OSI Darwin fix and XCPM disable for v3 Xeon

This configuration had been stable for over two years with no kernel panics, proper sleep/wake, and full GPU acceleration. The goal was to update Clover, Lilu, and WhateverGreen to their latest versions compatible with High Sierra, then validate that none of the ACPI patches broke.

Update Procedure

1. Full Backup and Snapshot

I cloned the entire macOS volume to a spare SATA SSD using SuperDuper! (bootable clone). Additionally, I saved the entire EFI partition — not just the EFI/CLOVER folder, but also the raw partition dump via dd if=/dev/disk0s1 of=/backup/efi_backup.img. This allowed recovery of the exact partition layout and hidden firmware files if the bootloader update corrupted the NVRAM region.

2. Bootloader Update: Clover r5099 → r5123

I used the Clover macOS installer package (pkg) rather than manual file replacement. During installation, I deselected all drivers except ApfsDriverLoader, AptioMemoryFix (not the newer OpenRuntime — dual-CPU X99 still works better with AptioMemoryFix on High Sierra), HFSPlus, and EmuVariableUefi (for NVRAM emulation). I kept the config.plist untouched during the install, then manually merged only the new booter options after reading the Clover r5123 changelog. The critical change was that Clover r5119+ introduced a different handling of KernelPm — I verified that my existing KernelPm flag remained true and that AppleCpuPmCfgLock and AppleXcpmCfgLock were still present.

3. Kext Update: Lilu 1.5.9 → 1.6.8 and WhateverGreen 1.5.9 → 1.6.6

I downloaded the releases from the respective GitHub repositories (verified checksums against the published SHA-256). I replaced the kexts in /EFI/CLOVER/kexts/Other and also updated the copies in /Library/Extensions (for Lilu and WhateverGreen, I kept them only in the bootloader kext folder to avoid SIP complications). After copying, I ran kextcache -i / to rebuild the prelinked kernel — this step often reveals dependency issues on dual-CPU systems because the kernel cache must include all CPU-related plugins. The rebuild completed without errors.

4. ACPI Verification

I did not change any SSDT or DSDT files during this update. However, I recompiled all AML files with iASL (version 20220310) to ensure they were free of warnings that newer Clover might interpret as errors. The original SSDTs were compiled with an older iASL that tolerated certain ResourceTemplate omissions — the recompilation caught one missing Buffer size in SSDT-UNC. I fixed it, recompiled, and replaced the file.

Post-Update Validation

After the update, I booted with -v debug=0x100 keepsyms=1 to capture any panic messages. The system proceeded through the following checkpoints:

• Early boot: No MACH Reboot or Panic(CPU 0, ...) — the Lapic kernel patch (necessary for dual-CPU systems with >16 logical processors) was still applied correctly.
• XCPM initialization: The kernel printed XCPM: registered for both processor packages. On older Clover versions, XCPM would sometimes register only for CPU0, causing high power consumption on CPU1. After the update, both packages reported identical P-state data in sysctl.
• NUMA node enumeration: sysctl hw.memsize reported 128 GB, and sysctl hw.ncpu returned 56. The dmesg output showed two NUMA nodes with correct memory proximity domains.

Graphics and Audio

I ran Geekbench 4 (the last version compatible with High Sierra) to stress both CPU packages. The multi-core score was 48,320 — within 2% of the pre-update baseline (47,890), which is normal thermal variation. GPU acceleration via the RX 580 was verified with VideoProc encoding a 4K H.264 file; no frame drops or artifacts appeared. Audio output via AppleALC (layout-id 1 for the onboard Realtek ALC1150) remained functional after the update — no need to change the codec injection.

Known Issues After Update

Two regressions appeared that were not present before:

1. USB 3.0 port drop on cold boot: The X99-E WS has an ASMedia ASM1042A controller for the rear USB 3.0 ports. After the Clover update, these ports would not enumerate on first boot unless I plugged a device into a USB 2.0 port first. The fix was adding new-way to the USBInjectAll quirk in config.plist under KernelAndKextPatches → KernelXCPM (yes, that quirk lives under an oddly named key). This is specific to Clover r5120+.
2. Wake from sleep takes 8 seconds longer: Previously, wake took ~3 seconds from S3. After the update, the system hangs for ~5 seconds at the Previous Shutdown Cause: 0 message before continuing. I traced this to the darkwake setting — changing darkwake=0 to darkwake=8 in boot-args reduced the delay to 4 seconds total. This appears to be a side effect of the updated AptioMemoryFix driver.

Neither issue causes instability, but they are worth documenting for anyone replicating this update path.

When Not to Update

If your dual-CPU system is running macOS Mojave or earlier, and you have a working configuration that boots reliably, there is no compelling reason to update the bootloader or kexts unless you are adding new hardware (e.g., a GPU that requires a newer WhateverGreen). The incremental improvements in Clover after r5100 mainly address APFS volume handling and OpenCore compatibility shims — neither matters for a pure High Sierra system. In fact, updating Clover beyond r5123 on X99 can break the KernelPm patch because later versions changed the patching mechanism. I deliberately stopped at r5123 after testing r5126 on a spare disk and observing random kernel panics under load.

For those still on Ivy Bridge-E (X79), the situation is even more constrained. The ACPI tables on X79 often require manual _PSS and _CST patches that newer Clover versions may ignore. If you are on X79, our guide on Stabilizing Ivy Bridge Hackintosh on macOS Sierra: ACPI Patches That Actually Work covers the specific SSDT modifications that must remain intact across bootloader updates.

Final Validation and Monitoring

After one week of uptime (the system serves as a compile server for legacy kexts), I checked the system log for any Wake Failure or AppleSMC timeout entries. None were present. The CPU package temperatures (monitored via istat menus on the secondary display) stayed within 2°C of pre-update values under identical load. The only operational change is the slightly longer wake delay, which I consider acceptable.

If you decide to update your own dual-CPU system, prepare a bootable USB with the exact previous EFI before touching any files. Test the new configuration for at least 48 hours of normal use — not just a single boot — because NUMA-related memory allocation issues can surface only after the system has been under memory pressure. And always keep a copy of the old config.plist with the KernelPm and Lapic patches explicitly commented so you can diff them against the new version.