The "Official" C612 (aka lets built the machine Apple never gave us)

[ttse7]

I am also thinking of using c612 to build a system. Can 10.11.5 be installed successfully ?

 

[infowolfe]

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?

Sorry to jump into your thread without having any hardware to contribute to the cause (I was curious... been looking at 2011-3 for my next workstation for ECC and virtualization)... but there is something I _can_ offer.

TL;DR the answer to your question is yes, C612 supports 1-4 sockets.

The 2011-3 E5v4 comes in a total of 3 flavors (that we know of, E5v1 came in 4 adding 1S FCLGA1356 to this list): 1S, 2S, 4S following the E5-1600v4, E5-2600v4 and E5-4600v4 model names. If further FCLGA1356 chips are released they'll be in the E5-1400v4 model name, though LGA1356 was only really used by HP/Dell in "lower end" professional workstations (currently covered by the E3v5 product lineup). The C612 chipset is used in some 1S and across all 2S and 4S Xeon E5v3 and E5v4 lines, though very few manufacturers have actually released 4S boards (SuperMicro only has the X10QRH+). Primarily the differentiator between C602J 4S E7v4/v3 and C612 4S E5v4/v3 is in RAS/fault tolerance features. The E7 memory controller specifically allows you to do realtime ECC memory "raid1" via lockstep mode or ECC "raid0" via independent channel mode, whereas the 4S E5's memory controllers only allow independent channel mode.

More info on anandtech: http://www.anandtech.com/show/9193/the-xeon-e78800-v3-review (see page 3 for memory)
for Broadwell HEDT E7's http://www.anandtech.com/show/10401...4800-v4-and-e78800-v4-families-up-to-24-cores
and Broadwell HEDT E5 http://www.anandtech.com/show/10158/the-intel-xeon-e5-v4-review

Anyway, whether you're building a 1S C612 or 4S C612, whether or not the sockets are populated likely has no effect on SSDT, you *should* be seeing 4 sockets in ACPI, especially if, like in the case of SuperMicro, the OEM has multiple systems based on the same chipset and therefore have a common codebase for BIOS/UEFI. The reason why you're seeing them is because there are quite a few tools (like linux dmidecode) that report on number of sockets and whether or not they're populated.

Something kinda fun about how Intel does its PCH/chipsets: on HEDT platforms, typically the "consumer" chipset is a cut down server variant (X99/DH82031 is a cut down C612/DH82029) on non-HEDT it goes the other way (C236 is a cut down Q170).

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

 

[metacollin]

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.

Anyway, thank you for saving me the time I would have spent going down that rabbit hole - I'll not worry about that.

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.
4. The X99 patch, fakecpuid (the kernelcpu patch works too, but is not ideal).
5. I am using nullcpupowermanagement.kext for now.
6. SMBIOS is MacPro 6,1

Anyway, I haven't had much time to work on the machine the past few days, but I am finally getting around to it. I am installing El Capitan for a second time (my internal drives hadn't arrived yet earlier), but once that has finished, I will get into the nitty gritties of how much is left to be done with the c612.

For now, here is a complete DSDT and SSDT dump, along with their disassembled .asl files. I also included PRAD.aml, which is referenced in SSDT-1.aml, but I was unable to correctly disassemble it. Probably not important, though it is the Processor Aggregator Device which is one way of performing power management on the cores.

It ought to be useful to anyone working on this, as it sounds like it will likely be common to all X10 series supermicro motherboards.


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?

 

[ttse7]

It means you can successfully install mac osx in a c612 based PC?

 

[metacollin]

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.

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).

Honestly, I don't think the C612 is really that much of an issue. People have OS X running smoothly on X99-based systems, and the X99 and C612 are nearly interchangeable from a software perspective.

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.

Also, 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.

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!

 

[ttse7]

Great work and thank for your reply, metacollin.

 

[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.

Yes and no. The structure that you were commenting on is reasonably static, it's the values associated with those structures that're sometimes dynamic. Specifically comparing our machines, we both have a list of

\_PR.CPUn

in our SSDT.aml, but the values (TDP, etc), number of steps and height of bins/pstates (4.6Ghz "light" o/c on my end) between your Xeon E5 and my i7-4790k are wildly different, as should be the number of cores represented AND the number of packages (sockets).

There's a few basics about ACPI that a lot of people don't really understand:

• It's code, just like any other, and is thus subject to change (and bugs) between BIOS/UEFI/Firmware versions, so a patched SSDT/DSDT aml that worked well on Bios v1.0 may not work or may break heavily on Bios v1.1
• For the most part, ACPI is templated, so there's huge swaths of commonality between implementations... BUT each vendor is able to ship whatever they want really and don't necessarily have to conform to spec.
• While some (very small) parts are in fact influenced by UEFI/BIOS configuration options, the majority of ACPI on your system will stay static, and even the parts that're variable will be relatively stable as long as your installed hardware doesn't change.
• The reason why we do so much ACPI/SSDT/DSDT patching in the hackintosh world is because of the vendor freedom addressed above.... for example Gigabyte's

  _SB.PCI0.EHC1

  and Apple's

  _SB.PCI0.EH01

  both cover the exact same hardware, but Apple doesn't properly recognize Gigabyte's naming.
• Because of that vendor divergence, a large portion of the cosmetic and functional changes to ACPI we perform are to align non-Apple ACPI syntax with Apple's so macOS will recognize those hardware configurations (see clover XMP detection, ssdtPRGen/CpuPm, etc).

Anyway, thank you for saving me the time I would have spent going down that rabbit hole - I'll not worry about that.

np

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.

1: Have you considered testing if a non-Xeon Devil's Canyon/Broadwell CpuID with similar features would work?
2: Good to know, though not all that surprising.
3: Yup. Both hot-plugging and eSATA need to be disabled on a per-port basis for AHCI to report a disk as "internal" to OSX. IF you're doing something like sharing VM storage via MacZFS though, you'll likely want to have *those* drives setup as hot-plug so that they can be "properly" ejected if need be. (I have a Ubuntu 16.04 VM that "takes over" my 60GB Intel SSD and 2x 2TB 7200rpm SATA disks, using physical disks for all 3 drives as a "bootcamp" config in Fusion).

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?

Scope wise _SB is \_SB is _SB_ (at least from what I can tell).

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.

Congrats!

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.

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?

Also, 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.

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_memory

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!

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?

 

[metacollin]

Again, thanks for the information! It sounds like ACPI generation is a lot like templated code generation in C++, but with hardware. Makes sense now, thank you.

Anyway, I am going to try all of your suggestions ASAP, starting with installing linux and windows later tonight, mostly to get some...ahem, pardon the phrasing... intel on these CPUs.

I am pretty busy today with other stuff unfortunately, and I'll give a more complete reply when I get a chance. Here is a little more info while I have time:

1: Have you considered testing if a non-Xeon Devil's Canyon/Broadwell CpuID with similar features would work?

Nope. Even with a MacPro 6,1 SMBIOS? Well, I can give it a shot tonight, it's easy enough to test.

Have you booted linux on the system with those CPUs installed?

Not yet, but that's the plan for the immediate future. Also going to see what CPU-Z spits out in Windows (if needed anyway, going to see what I can find out in linux first).

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.

Yes, soon . My next reply will have some attached, but don't have any at the moment. I am no stranger to serial debugging, I have the hardware needed to connect to the serial console, just haven't bothered yet.

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?

Soon . I attempted to boot with the iMac 16,1 (Broadwell U) SMBIOS but I only tried my current ivybridge xeon CPUID (0x306E4), my actual CPUID (0x406F0) and a retail broadwell xeon cpuid (0x406F1). I need to try some more combinations, and will. Feel free to suggest any, otherwise I'll use my best guesses at likely possibilities. Oh, and with the MacPro6,1 SMBIOS I tried 0x306F2, the Haswell-EP CPUID.

You can actually "fix" the ram thing in Clover Configurator.app or in config.plist under the SMBIOS tab.

Already have that setup, but it isn't working for some reason. I've attached my current config.plist, which will also let you see exactly which patches I am using. Also, activity monitor reports nonsense memory information:

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 100% agree, and this is 'on the list' hehe. I just wanted to get immediate gratification functionality at first, but I am very much about doing things in the most robust and clean way possible, given enough time to work it out.

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?

Unfortunately, I do not think the X10DAI has IPMI support . But I completely understand the feeling you have of wanting to get something working and figure out why it is not . This is a production machine (or will be once arch linux is up and running), and hopefully I can migrate entirely to OS X eventually. But I am happy to give you as much information/logs/even setup remote serial access (if that is of any use, the remote options are pretty limited with no IPMI obviously). And just to be clear, my goal is to figure out how to get OS X working smoothly on hardware like this for the benefit of everyone. In fact, that's a big reason I went with this setup, with the intention of seeing if it could be done, then sharing it with the community. I am less concerned with my specific machine working smoothly, though that would be nice. The strange CPUs might prove problematic, I don't know.


I am using clover r3579 compiled from the svn repo, as well as r3577 depending on what I am booting from (I wanted to make sure I didn't screw up something with my self compiled version).

Anyway, I'll provide some real information about the panics and by all means, request any more info and I will try to include it in my next reply (which should be in the next day or so hopefully). For now, I've attached a boot.log, and my config.plist. Oh, and ignore the min/max CPU multipliers, I had entered those by hand at one point, but they're ignored right now.

 

[metacollin]

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!

X86platform/shim both loaded, and I ran geek bench again....and I managed to drop my multicore score by almost 16,000 points!

And increased my single core score by over 1000 points!

I think I screwed up .


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.


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?

I seem limited in SMBIOS selection as well. I can't even get past sleep state initialisation with any other SMBIOS... But that's ok, Mac Pro 6,1 is working fine.

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.

 

[infowolfe]

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!

OMG, YES! nice one!

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.

Maybe launch/use Intel Power Gadget to watch your clocks?
Also perhaps look at https://sourceforge.net/projects/hwsensors/

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?

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.

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.

Well, if you're using "standard" ALC audio layout, AppleALC.kext (https://github.com/vit9696/AppleALC) might be an option for you. Congrats on everything else though! Your progress is making me beyond excited to replicate it myself when my budget will allow it.