Building a Dual-CPU Hackintosh on X79 and X99: A Practical Guide

A dual‑CPU Hackintosh on Intel X79 or X99 will kernel panic early in boot unless you patch ACPI tables and configure the bootloader for the second CPU. The root cause: macOS expects a single System Management Interrupt (SMI) per CPU package, but a dual‑socket system presents two independent packages connected via QPI (X79) or UPI (X99). The kernel’s ACPI interpreter chokes on the second CPU’s PSAT (Processor System Affinity Table) or on how the firmware exposes processor topology. The typical panic is a EISA or ACPI_SMC_PlatformPlugin fault. This project attracts experienced enthusiasts who already own compatible hardware, but it introduces problems absent in single‑socket builds.

Before diving into patches, understand the hardware constraints. Only a few chipsets support dual‑socket configurations with acceptable macOS compatibility: Intel C602 (X79) and C612 (X99). The X79 chipset paired with dual Xeon E5‑2600 v1/v2 processors is the most documented, partially because the X79 ACPI tables are simpler than those on X99.

The X99 chipset, while offering more PCIe lanes and DDR4 support, introduces a more complex CPU topology (up to 18 cores per socket) and requires extra SSDTs to define the processor objects. Neither platform will ever see full native CPU power management for both sockets—macOS lacks the necessary XCPM (XNU CPU Power Management) support for multi‑package systems, so you will have to rely on a patched AppleIntelCPUPowerManagement.kext or use a CPU‑PM SSDT generated by tools like ssdtPRGen. Even then, expect higher idle power consumption and no Turbo Boost on the second package.

Selecting Compatible Motherboards and CPUs

Not all dual‑socket boards work equally well. The safest choices are:

• X79: Supermicro X9DAi, Gigabyte GA‑X79‑UP4, ASUS Z9PE‑D8 WS (rev 1.0x only). Avoid boards with Broadwell‑EP support (X79 rev 2.x) because those often require a BIOS update that breaks ACPI compatibility with macOS.
• X99: Supermicro X10DAi, ASUS X99‑E WS, Gigabyte GA‑X99‑Designare EX. The X10DAi tends to have the most straightforward DSDT.

CPU selection matters because macOS’s kernel performs a microcode‑based step check on every core. Mismatched steppings (e.g., one CPU with stepping C0, the other with C1) can cause random kernel panics during heavy load. Always use two identical processors with the same stepping and batch code. The E5‑2690 v2 (3.0 GHz, 10 cores) is a popular choice because it balances core count with per‑core performance and is well‑supported by the patched power management kexts.

ACPI Patching for Dual CPU

The default DSDT on a dual‑socket board usually contains a Processor object for each logical core, but macOS’s ACPI implementation expects a flat list of CPU objects under the main processor bus. The key fix is to replace the Processor blocks with Device (CP00) wrappers and to inject a plugin‑type SSDT that tells the kernel’s CPU manager the correct topology. The following steps are necessary:

1. Dump the DSDT and all SSDTs from the BIOS using Clover’s F4 key or a Linux live USB with acpidump.
2. Identify the second CPU’s processor objects—they are usually named PRP0 or PRP1 in X79, or P00 / P01 in X99. These must be manually renamed to CPU0 and CPU1 in the DSDT.
3. Create an SSDT that defines the CPU topology using the Device (CP00) format with a _PPC, _PSS, and _CST methods. The ssdtPRGen tool can generate such an SSDT, but you must edit the script to set #define MAX_CORES to the total logical core count (e.g., 20 for dual E5‑2690 v2 with Hyper‑Threading).
4. Disable NUMA (Non‑Uniform Memory Access) in the bootloader. macOS does not handle NUMA gracefully; it can allocate memory across sockets in a way that degrades performance. Add npci=0x2000 and cpus=1 (temporarily for testing) or use a kernel patch that disables NUMA detection. The most reliable method is to patch the kernel’s _numa_available function to return 0. On 10.13 High Sierra, this can be done with a Clover kernel‑to‑patch entry: Find: 31C0C3 → Replace: B000C3 (for 64‑bit kernel).

Bootloader Configuration

Both Clover and OpenCore can handle dual‑CPU systems, but OpenCore gives finer control over ACPI patching. If you are already familiar with Clover, you can use it—just be aware that Clover’s FixDsdt masks may break the secondary CPU beyond repair. Stick to manual DSDT modifications. For a detailed comparison of the two bootloaders on X79 and X99, see the Clover vs OpenCore for Legacy Hackintosh: X79, X99, Z170, Z270 on Sierra Through Mojave article.

Essential boot‑args for dual CPU:

• npci=0x2000 – disables PCIe secondary bus enumeration issues (common on X79).
• keepsyms=1 – useful for debugging panics.
• debug=0x100 – shows panic log.
• cpus=1 – only for initial testing; never leave it enabled.
• slide=0 – may help with memory allocation on dual‑socket boards.

Under Kernel and Kext Patches in Clover, or Kernel > Patch in OpenCore, add the NUMA disable patch. For High Sierra (10.13.6), the signature is:

Comment: Disable NUMA
Find: 31C0C3
Replace: B000C3
Count: 1

For Sierra (10.12.6), the find/replace may differ—verify with a hex dump of the kernel file.

Sleep, Wake, and Graphics

Dual‑CPU systems frequently fail to wake from sleep because the second CPU’s power state is not restored correctly by the kernel. The only reliable workaround is to disable sleep entirely: set hibernatemode to 0 and use pmset -a sleep 0. If you absolutely need standby, experiment with darkwake=0 and a custom SSDT that forces all cores to the same C‑state on wake. This is rarely stable, so consider it a research project rather than a daily‑driver feature.

Graphics are less problematic: any GPU that works on a single‑CPU Hackintosh will work on a dual‑CPU system. The caveat is that the second CPU’s PCIe lanes are tied to the second socket; if you install a GPU in a slot controlled by the second CPU, macOS may not recognize it because of the ACPI routing. Always install the primary GPU in a slot directly attached to the first CPU (usually slot 1 or 2 on the board).

Performance and Stability Expectations

Do not expect linear scaling. A dual‑CPU Hackintosh shines in workloads that are trivially parallelizable (e.g., video encoding, 3D rendering) but suffers in single‑threaded tasks due to inter‑socket latency. In macOS, the kernel’s scheduler can place threads on the second CPU, but the cache coherency penalty is higher than on a single‑socket system. You may also encounter random kernel panics related to the AppleCPUPM kext refusing to load for the second package. The fix is to replace the kext with a version patched for dual‑socket support, or to use a NullCPUPowerManagement kext (which disables native power management entirely).

For a concrete example, a dual E5‑2690 v2 system (20 cores / 40 threads) running High Sierra 10.13.6 achieved a Cinebench R15 multi‑core score of about 3200, which is roughly 1.5× the score of a single E5‑2690 v2 (2200). The 50% improvement, not 100%, is due to the memory latency and NUMA overhead. The system was stable for weeks of rendering work, but only after disabling sleep and carefully tuning the ACPI patches.

Risks and Data Safety

Modifying ACPI tables and kernel patches carries a high risk of data loss if the system panics while writing to disk. Always back up your EFI partition and any important data before attempting a dual‑CPU build. Keep a bootable USB stick with a known‑good config. If you are not comfortable extracting and patching DSDT files, dual‑CPU Hackintosh is not a beginner project.