We are very close to a smoothly running c612 hackintosh I believe. I'd like to report a successful boot and install of 10.11.5 as well. I am using a Supermicro X10-DAI motherboard, and dual Xeon 2690v4 CPUs (engineering samples no less, for Hard Mode hackintoshing), GTX 960 GPU. Currently attempting to get power management/speedstep/turbo working. I don't think the SSDTs I generated work correctly, I may need to patch the DSDT.
Supermicro puts CPUs under \_SB.SCKx.CPxx. Where SCKx is SCK0-4, I presume socket 0-4 (does the C612 support quad CPUs too? Odd, regardless). Same with its SSDTs. And, strangely, the number of sockets/CPUs does not reflect what is installed, but always yields the maximum. This might be a quirk of using engineering samples, I am not sure.
Anyway, I'll report back here once I convince OS X to power manage some broadwell xeons. Should be easy, right?
Metacollin/Seandonnelly: I'm very much interested in the subject of C612 support and would be happy to help with both ACPI (SSDT/DSDT) and PM. I'm currently running a GTX 980 Ti w/ web driver, so can likely help there as well. skype/gtalk/freenode: infowolfe
Infowolfe, thanks for that information, it was extremely helpful. I was under the impression SSDT/DSDT was generated dynamically based on hardware configuration by the bios, so could vary based on settings and hardware configuration but it sounds like I'm mistaken. Oh, I'm an electrical engineer and programmer, but iASL is new to me, so bear with me as I learn, but I like to think I have the background to get support going. I am no stranger to reading datasheets =P.
\_PR.CPUn
_SB.PCI0.EHC1
_SB.PCI0.EH01
Anyway, thank you for saving me the time I would have spent going down that rabbit hole - I'll not worry about that.
1: Have you considered testing if a non-Xeon Devil's Canyon/Broadwell CpuID with similar features would work?So, what I know so far:
1. The machine reboots immediately upon kernel transition due to the CPUID, which is to be expected. At the moment, I am using the fake cpuid of 0x0306E4, which of course is the CPUID of a v2 Xeon.
2. The X99 kernel patch works for the c612 as well, at least for booting.
3. I am using mostly default bios settings, I did have to turn off hotplug capability for the internal SATA drives to have OS X recognize them as internal. Though, I feel like this is not a bug so much as correct behavior, since OS X would still need you to eject the disk for hot plugging. In my case, I am not going to be doing that however.
The nice thing is that there doesn't seem to be any errors in the DSDT table that needs patching, but it looks like there might be some scope issues between the SSDT and DSDT. _SB vs \_SB. I am guessing, still reading up on the ACPI Spec. PDF is only 1080 pages, shouldn't take but half an hour, right? . Kidding, but I am looking through it. Is there anywhere that specifies the subset of ACPI that OS X uses?
Congrats!Yep! I'm typing this from Safari in OS X 10.11.5 running on my C612 workstation. I've got my GTX 960 working great too. Everything seems to be running smoothly, no weird lag or other odd behavior that I've seen mentioned in X99 threads.
Have you booted linux on the system with those CPUs installed?It's also worth mentioning that I am using Broadwell-EP CPUs (Xeon E5 V4s). For now, power management is just totally screwed, I have been totally unable to get past AICPUPM panics, and haven't had a chance to make a serious attempt at generating SSDTs. I also need to install windows to figure out some specs on these CPUs of... questionable origin (eBay =P).
The part that might be a more of a problem is the CPUs. There seems to be good support for Haswell-E platforms, but that's with the 5960X. I'm having to use a fakecpuid for the Ivybridge-EP (v2 Xeon) platform to boot at all, and I've been unable to get any haswell or broadwell E or EP CPUID to boot. This is likely due to using a MacPro 6,1 SMBIOS which of course expects an ivybridge Xeon CPU. As near as I can tell, using this SMBIOS is required for C612 support however.
You can actually "fix" the ram thing in Clover Configurator.app or in config.plist under the SMBIOS tab. There's options for 'Channels' (you'll want 8) and 'SlotCount' though you can actually define what's in your system specifically on a by-DIMM basis if you prefer. It's primarily cosmetic, though (afaik) as I'm not sure Apple's actually built any functional NUMA-awareness and/or processor/socket affinity into macOS. https://clover-wiki.zetam.org/Configuration/SMBIOS#smbios_memoryAlso, another oddity, is it only sees 4 of my 16 RAM slots, and 2 of them are unoccupied ones (as they should be - I've installed 8X8GB DDR4 sticks in the correct slot population order). I hope to address that soon as well, but I'm still getting up to speed.
Have you looked into using the "stock" clover network enablement stuff? I'm kinda a firm believer in the idea that we should attempt to achieve as much as possible from within clover instead of via the more fragile patched/custom kexts route..Good news is networking works with the maui kexts, both CPUs and all 28 physical cores (56 logical-hyper threading works fine) are recognized and used by OS X.
No turboboost or anything that smells remotely like CPU power management for now. But even in this semi-crippled state, I managed a multicore geekbench score of 62017.
I uploaded an earlier, slightly lower score to the geekbench site. If you search for "Mac OS X" on the geekbench site and sort by multicore score, you can find me in spot #3. However, I think I can break 70000 though once turbo is working.
But if not...I'm hardly unhappy with the performance, that's for sure!
1: Have you considered testing if a non-Xeon Devil's Canyon/Broadwell CpuID with similar features would work?
Have you booted linux on the system with those CPUs installed?
Can you setup a video/photo screen capture or find the logs and get the specific panic output? If you're having problems, there are also macOS kernel and clover options for debugging via serial port we could explore.
Have you talked to pikeralpha about ssdtPRGen for your cpus? Which Haswell/Broadwell-EP cpuids have you tried? As I asked above, have you tried using a Broadwell SMBIOS?
You can actually "fix" the ram thing in Clover Configurator.app or in config.plist under the SMBIOS tab.
Have you looked into using the "stock" clover network enablement stuff? I'm kinda a firm believer in the idea that we should attempt to achieve as much as possible from within clover instead of via the more fragile patched/custom kexts route..
I'm jealous as could be and would *love* to have your system even if only for a little bit. Does your board by chance have IPMI? If not, could you record and/or log some of these panics? I'm also rather curious about why the Haswell-E kernel patch isn't working for you, as your cpu's supposed to be just a die-shrunk Haswell-E. Oh... which patch(es) are you using exactly... and which version of Clover?
OMG, YES! nice one!Great news, after changing my fakecpuid to 0x0306F0, I was able to resolve the AICPUPM panics, and saw XCPM was getting registered. I generated an SSDT by, uh, just making stuff up (basically what I hoped these engineering samples turbo might be, etc). Armed with this, I rebooted and low and behold... native xnu power management!
I think!
Maybe launch/use Intel Power Gadget to watch your clocks?I certainly appreciate the utility of higher single thread performance...but I got this machine for dem cores. Parallel/multicore performance is definitely my priority.
Also, oddly, no matter what I do, loading AppleIntelInfo.kext causes and instapanic and a prompt reboot. That said, I think power management is doing, uh, something, considering the effect it had on my scores.
Actually, sounds like you might be hitting socket power limits. Multi-core locked turbo isn't really a thing on Xeon systems, unlike what you can do with adjusting/locking turbos on i-series cpus. Basically, if your socket power limit is 160W TDP, your cpus won't stay at their highest turbo as more cores are loaded up. I *do* recommend finding out the turbo steps in linux (try i7z). I'd also like to see a screenshot of cpu-z if you don't mind doing it. I'm willing to bet that your lower multi-core geekbench is the result of macOS asking for the wrong steps. You may want to check in your bios to see if there's a place for you to adjust the turbo frequencies. In desktop BIOS there's usually a place where you can go in and adjust both the individual socket power limits but also the max turbo frequency on a per-core basis. If not, you're going to be stuck with whatever the stepped turbo limits are. Generally you'll start with 1 core at max clock, then drop by a bin (100mhz) per further core used. I will warn you: if ssdtPRGen's DSDT doesn't match your cpus multipliers you won't hit max turbo.I guess I need to actually find out what the data are for these CPUs. I wonder if maybe setting the maximum turbo too high resulted in the all-core turbo being lower than it should be?
Also, ram fixed. I didn't realize I needed to actually fill in ram modules in addition to setting slot count. I've done that and now all 16,of my slots are reported and all memory related usage/pressure/stats seems to be correctly reported now.
Oh, and networking is working 100% native now. I'm not using any kexts besides fakesmc.
Progress is being made, I think a fully functional and smooth running C612-based broadwell-EP hackintosh is very close to being a reality. I will definitely make an actual rough guide when or if everything gets worked out.
One thing I've mostly ignored but is not responsive to any clover fixes is the audio. After native speed step/turbo is squared away, that's probably next on the list.