Broadwell-E Hackintosh on High Sierra: Required Kexts, ACPI Patches, and Bootloader Config
Step-by-step guide to running Broadwell-E CPUs (6800K, 6850K, 6900K, 6950X) on macOS 10.13 High Sierra with X99 chipset. Covers FakeCPUID, NullCPUPowerManagement, ACPI patches, Ethernet/audio fixes, and troubleshooting boot failures.
Broadwell-E (LGA 2011-3) processors — the 6800K, 6850K, 6900K, 6950X — occupy a strange position in the Hackintosh timeline. Released in mid-2016, they were the last enthusiast-grade Intel CPUs to use the X99 chipset before the X299 platform took over. Apple never shipped an X99-based Mac Pro, yet High Sierra (10.13) runs on these CPUs with surprising stability — if you know the exact kext, ACPI, and bootloader configuration required. This guide covers the specific compatibility boundaries, known pitfalls, and reproducible steps for a working Broadwell-E system under macOS 10.13.6.
Broadwell-E vs Haswell-E: What Actually Changed
From a pure architecture standpoint, Broadwell-E is a die-shrink of Haswell-E (14 nm versus 22 nm) with the same LGA 2011-3 socket and X99 chipset. The critical differences for macOS are the CPU ID, the integrated memory controller's handling of DDR4, and the way ACPI tables report processor objects. High Sierra's kernel expects a certain CPUID signature for power management; Broadwell-E reports as 0x0406F1, which macOS 10.13 does not natively recognize. Without a patched kernel or a fake CPUID, the system will panic early in boot — usually a panic(cpu 0 caller ...) related to AppleIntelCPUPowerManagement.
Haswell-E CPUs (5820K, 5930K, 5960X) report 0x0306F2 and work out of the box in High Sierra with minimal ACPI tweaks. Broadwell-E requires explicit fakery. This is why many older X99 guides simply recommend sticking with Haswell-E for a trouble-free build, but if you already own a 6800K or 6900K, the fix is straightforward.
Required Kexts and Bootloader Configuration
For a stable Broadwell-E Hackintosh on High Sierra, you need three kexts and one bootloader argument:
- FakeSMC.kext — mandatory for any Hackintosh; version 6.26 or later recommended.
- NullCPUPowerManagement.kext — disables the native CPU power management that panics on unrecognized CPUIDs. Some users replace this with a patched
AppleIntelCPUPowerManagement.kext, but NullCPUPowerManagement is simpler and less error-prone for Broadwell-E. - Lilu.kext + WhateverGreen.kext — needed for correct graphics initialization, especially if using an NVIDIA GPU with the Web Drivers.
- Boot argument
cpus=1— temporary diagnostic tool if you suspect a core-count related panic; do not leave it in daily use.
In your bootloader config (Clover or OpenCore), set FakeCPUID to 0x0306F2 (Haswell-E signature). This tricks macOS into loading the correct power-management plugin. Without this, even with NullCPUPowerManagement, the system may boot but will lack proper frequency scaling and sleep will fail.
If you are using OpenCore, the relevant entry in config.plist under Kernel -> Emulate is DummyPowerManagement — set it to True instead of relying on NullCPUPowerManagement. OpenCore's approach is cleaner and avoids conflicts with other kexts.
ACPI Patches Specific to Broadwell-E
The X99 chipset's ACPI tables are notoriously non-standard. Broadwell-E adds extra complexity because the SSDTs may contain references to CPU objects (PR00 through PR09 for a 10-core 6950X) that macOS cannot parse without a patch. The most reliable method is to use a pre-built SSDT for X99 that replaces the entire CPU-scope definition. The Fixing ACPI Panics on X79/X99 Hackintosh for macOS High Sierra article covers the general approach; for Broadwell-E specifically, you must also rename _PR_.CPU0 to _PR_.CP00 and adjust the PNOT method to avoid a NULL pointer dereference in the IOPCIFamily kext.
Another common ACPI issue is the EC (Embedded Controller) device. X99 boards often have an EC that macOS expects to find, but the ACPI table names it EC0 instead of EC. A simple rename patch (EC0 -> EC) in your bootloader config resolves this. Without it, you may see a five-second delay at boot while the kernel waits for the EC to respond.
Ethernet and Audio: Known Working Configurations
Most X99 boards use the Intel I218-V or I210-AT Ethernet controller. The I218-V works with IntelMausiEthernet.kext (version 2.5.0 or later) in High Sierra. The I210-AT requires SmallTreeIntel82576.kext or the modified AppleIGB.kext. Realtek RTL8111 variants also appear on some X99 boards; for those, refer to the Fixing Realtek RTL8111 Ethernet on Hackintosh High Sierra: Chip Revisions, Kexts, and ACPI Patches guide — note that Broadwell-E systems may need an additional SSDT-EC.aml to prevent a kernel panic related to the Ethernet controller's power state.
Audio codecs on X99 boards are typically ALC1150, ALC1220, or ALC892. AppleALC.kext (with Lilu) supports all three in High Sierra. Use layout-id 1, 2, 3, 5, or 7 depending on your board's specific codec configuration. A common mistake is forgetting to add the hda-gfx property to the GPU device in the ACPI; without it, HDMI audio output will not appear even if the codec is correctly detected.
Diagnosing Boot Failures
If your Broadwell-E system hangs at [EB|#LOG:EXITBS:START], the most likely cause is an incorrect FakeCPUID or a missing DummyPowerManagement setting. Boot with -v and watch for the line AppleIntelCPUPowerManagement: (PID: 0) panic — that confirms the CPUID mismatch. Another common failure point is the XCPM (XNU CPU Power Management) kext crashing on Broadwell-E. If you see XCPM: unsupported CPU in the verbose log, add -xcpm boot argument to force-disable it, though this may reduce performance slightly.
Sleep/wake issues are endemic to X99. Broadwell-E systems often wake immediately after sleeping due to a USB device or a misconfigured _PRW method in the DSDT. The quick fix is to map all USB ports with USBInjectAll.kext and a custom SSDT-UIAC.aml, then enable FixOwnership in the bootloader's ACPI settings. If the system still wakes, check the DarkWake logs with pmset -g log and disable any XHCI handoff in the BIOS.

Performance and Stability Trade-offs
Broadwell-E under High Sierra performs within 5% of the same CPU running Windows 10, provided you use the correct power-management profile. The 6950X (10 cores, 20 threads) is particularly well-suited for multi-threaded workloads like video transcoding or compiling, but single-core turbo boost is limited to 3.5 GHz — noticeably slower than a contemporary Kaby Lake CPU at 4.5 GHz. For gaming or single-threaded tasks, the Kaby Lake Conundrum: CPU Compatibility in Sierra 10.12.4 highlights why a Z270 build may be a better choice despite the older platform.
One persistent instability on Broadwell-E is random kernel panics under heavy memory load, especially with quad-channel DDR4 configurations running above 2666 MHz. High Sierra's memory controller driver is not optimized for Broadwell-E's mesh interconnect; the safe upper bound is 2400 MHz. If you experience panics during memory-intensive tasks, drop the RAM speed to 2133 MHz in BIOS and test stability with memtest86 for at least one full pass.
Preserving Your Configuration
Once you have a stable Broadwell-E High Sierra installation, back up the entire EFI partition and the contents of /Library/Extensions. Keep a copy of your working config.plist and any custom SSDTs in a version-controlled folder. X99 Broadwell-E is a niche within a niche; six months from now, a minor macOS update or a bootloader change could break your setup. Having a known-good configuration on hand saves hours of re-diagnosis. If you are assembling a new build from scratch, consider whether the extra cores of a 6950X justify the additional ACPI patching over a simpler Haswell-E setup — the answer depends entirely on your workload.
