Help installing Mojave on Xeon W-2175 and Asus WS C422 mobo

[obus]

7 minutes ago, apianti said:

Yes the difference is the firmware.

 

EDIT: I realize that you CAN buy those CPUs outside the supply chain, but I was trying to say that they are most likely not similar enough for the firmware to know what to do with extra stuff I'm assuming is there or why did they have special mac-only models made when it would have been cheaper to source already made CPUs?

 

According to PikerAlpha: "Both running with a lower base frequency than the W-2145 (3.7GHz) and W-2155 (3.3GHz). And there can only be one reason for this. Heat!".

https://pikeralpha.wordpress.com/2017/10/08/intel-to-remedy-heat-for-apples-new-imac-pro-with-special-xeon-w-skus/#comment-12352

 

The discussion here is interesting because obviously there was some problem in the beginning with the  i9-7900X processors similar to our problems.

[apianti]

Nah, I think he's incorrect. The reason being that the W-2135 is only 6(12) cores, where the W-2140b and W-2145 are 8(16), and the W-2150b and W-2155 are 10(20). However, I would expect that the W-2145/W-2155 would be better than the W-2140b/W-2150b respectively or why not name the cpu the same (or to even differentiate that it was mac-only with just the b)? So the higher clock speed for the W-2145 and W-2155 makes sense, they have similar turbo freqencies (also with the W-2135 but it has less cores, specifically the third number multiplied by 2 is the core count). Comparing the W-2170b and W-2175, or the W-2191b and W-2195, they are the exact same it appears (though I have a feeling they are not because again why would they make two different versions of the same chip with just a different identifier?). The models then all get slower as the identifier increases as the TDP stays the same (140W) but the core counts increase, meaning there is less power for each core. The thing to note is that all of the mac-only models were announced in june of 2017 when they introduced the imacpro, but weren't released until the imacpros actually came out in december. The other models were announced and released all on the same day in august 2017. This is actually probably a misleading thing though, as most likely the mac-only models were engineered first, much sooner than june and shipped to apple because they then needed to build the imacpro, which needed to be ready by june (because that's when they announced and showed it) but weren't actually released until december. So I think they had the chips already at that point in june, putting the manufacture date at the very beginning of 2017 or end of 2016. Why does intel then wait until august 2017 to announce the consumer available w series, only as the series is released? They probably weren't engineered until early-mid 2017. I would think that the mac-only models are actually probably the specs apple wanted and the others are what intel thought consumers would buy at specific price points after having engineered the models for apple, not wanting to waste a process as they could sell more commercially than to apple alone (not to mention they probably get more money from consumers than from apple per cpu). You can also look that they did not release any W-216X or W-218X cpus (which would be 12 and 16 cores and no other models in the W series have those core counts). Why also name the one randomly W-2191b when the other mac-only models end in 0? Maybe they intended to release those models but ended up changing their minds and there would have been a W-2190 which would be slower than the W-2191b (or maybe they still may release them). After reading what he says in his post, he even appears to state a better reason than heat for the difference, they actually are different and have integrated graphics. Then he states the integrated graphics are disabled by the OS, more implication here on my part, but I imagine this is what is causing the issues. On a mac, the integrated graphics are initialized by the firmware but then disabled by the OS, this is perfectly acceptable. On non macs, the integrated graphics are not initialized but then the OS tries to disable the integrated graphics, this is an issue, especially when there is no integrated graphics (not using a mac-only model). The firmware for C422 probably doesn't even attempt to initialized integrated graphics because well it doesn't actually support integrated graphics (https://ark.intel.com/content/www/us/en/ark/products/126691/intel-c422-chipset.html). This is an interesting read (https://www.pcgamer.com/heres-what-you-need-to-know-about-kaby-lake-x/), maybe the mac-only models are actually re-purposed skylake cores with integrated graphics as well that can't actually work because of the C422 chipset not supporting integrated graphics. I wonder if the other models are actually a different process then or not... Lots of information here, and some speculation..... I think you have discovered you have two ways to configure to get working system and power management with the w series, fakecpuid + patch _xcpm_pkg_scope_msrs, or bootstrap patch + frequency vectors.

 

EDIT: Oops, I meant skylake for the w series, not kaby lake, lol.

Edited April 12, 2019 by apianti

[obus]

3 hours ago, apianti said:

Nah, I think he's incorrect. The reason being that the W-2135 is only 6(12) cores, where the W-2140b and W-2145 are 8(16), and the W-2150b and W-2155 are 10(20). However, I would expect that the W-2145/W-2155 would be better than the W-2140b/W-2150b respectively or why not name the cpu the same (or to even differentiate that it was mac-only with just the b)? So the higher clock speed for the W-2145 and W-2155 makes sense, they have similar turbo freqencies (also with the W-2135 but it has less cores, specifically the third number multiplied by 2 is the core count). Comparing the W-2170b and W-2175, or the W-2191b and W-2195, they are the exact same it appears (though I have a feeling they are not because again why would they make two different versions of the same chip with just a different identifier?). The models then all get slower as the identifier increases as the TDP stays the same (140W) but the core counts increase, meaning there is less power for each core. The thing to note is that all of the mac-only models were announced in june of 2017 when they introduced the imacpro, but weren't released until the imacpros actually came out in december. The other models were announced and released all on the same day in august 2017. This is actually probably a misleading thing though, as most likely the mac-only models were engineered first, much sooner than june and shipped to apple because they then needed to build the imacpro, which needed to be ready by june (because that's when they announced and showed it) but weren't actually released until december. So I think they had the chips already at that point in june, putting the manufacture date at the very beginning of 2017 or end of 2016. Why does intel then wait until august 2017 to announce the consumer available w series, only as the series is released? They probably weren't engineered until early-mid 2017. I would think that the mac-only models are actually probably the specs apple wanted and the others are what intel thought consumers would buy at specific price points after having engineered the models for apple, not wanting to waste a process as they could sell more commercially than to apple alone (not to mention they probably get more money from consumers than from apple per cpu). You can also look that they did not release any W-216X or W-218X cpus (which would be 12 and 16 cores and no other models in the W series have those core counts). Why also name the one randomly W-2191b when the other mac-only models end in 0? Maybe they intended to release those models but ended up changing their minds and there would have been a W-2190 which would be slower than the W-2191b (or maybe they still may release them). After reading what he says in his post, he even appears to state a better reason than heat for the difference, they actually are different and have integrated graphics. Then he states the integrated graphics are disabled by the OS, more implication here on my part, but I imagine this is what is causing the issues. On a mac, the integrated graphics are initialized by the firmware but then disabled by the OS, this is perfectly acceptable. On non macs, the integrated graphics are not initialized but then the OS tries to disable the integrated graphics, this is an issue, especially when there is no integrated graphics (not using a mac-only model). The firmware for C422 probably doesn't even attempt to initialized integrated graphics because well it doesn't actually support integrated graphics (https://ark.intel.com/content/www/us/en/ark/products/126691/intel-c422-chipset.html). This is an interesting read (https://www.pcgamer.com/heres-what-you-need-to-know-about-kaby-lake-x/), maybe the mac-only models are actually re-purposed kaby lake cores with integrated graphics as well that can't actually work because of the C422 chipset not supporting integrated graphics. I wonder if the other models are actually a different process then or not... Lots of information here, and some speculation..... I think you have discovered you have two ways to configure to get working system and power management with the w series, fakecpuid + patch _xcpm_pkg_scope_msrs, or bootstrap patch + frequency vectors.

Hi @apianti

I really enjoyed reading this post (Bachelor degree level), and  I very much appreciate your efforts to try to explain and shed some lights over this complex stuff. I think the conclusion of all this is that we, for the moment, have to live with a "non-native" processor, and try to do the best of the situation and use the tools that is available. As long as we have a working_xcpm_pkg_scope_msrs patch everything is working like a charm.

Thank's again @apianti for your hard work with Clover and give us a hint if you have any news regarding our specific problems.

 

[yapan4]

A lot of information from @apianti, takes a little time to process it.

The conclusions are now being reversed - it is:
  1) CPU problems
  2) BIOS problems

Solution:
1) Change CPU to Apple (with "B" letter)
2) Ask the ASUS to add support such CPUs in BIOS, he-he...

[apianti]

5 hours ago, obus said:

Hi @apianti

I really enjoyed reading this post (Bachelor degree level), and  I very much appreciate your efforts to try to explain and shed some lights over this complex stuff. I think the conclusion of all this is that we, for the moment, have to live with a "non-native" processor, and try to do the best of the situation and use the tools that is available. As long as we have a working_xcpm_pkg_scope_msrs patch everything is working like a charm.

Thank's again @apianti for your hard work with Clover and give us a hint if you have any news regarding our specific problems.

 

Yeah, no problem. I wanted to get down to the lower level as much as possible without having the actual hardware. I think either way of patching I suggested will work, so whichever you find easier is probably the better choice and that's probably fakecpuid + patch _xcpm_pkg_scope_msrs. I think you guys are having a misnomer about non-native processor, regardless of whether or not you have the exact same hardware in a mac (this is entirely possible to achieve for some mac models, I have this for iMac12,2), you still need patches because even if the problem is panic/crash (or even unsupported hardware) the cause is always software and the only thing that can be done is to patch it. The main thing is that apple firmware and actually UEFI compliant firmware for PCs are just different and apple expects that certain things will always be, because that's how they made it...

 

2 hours ago, yapan4 said:

A lot of information from @apianti, takes a little time to process it.

The conclusions are now being reversed - it is:
  1) CPU problems
  2) BIOS problems

Solution:
1) Change CPU to Apple (with "B" letter)
2) Ask the ASUS to add support such CPUs in BIOS, he-he...

 

I think it's actually firmware issues and OS software issues, I don't think the CPU really plays much of a role other than having an id that seems to cause an issue for the OS. Since the bootstrap patch worked for you guys I would think that the probably is strictly related to either xcpm bootstrap jump is wrong for that id like it was for the original cpu it was made for, it may be possible to find a correct bootstrap patch to have it corrected. Or the only other cause really is the state of the devices, which is set by the firmware.

[yapan4]

@apiantiThank you again.
I tested only two options in bootstrap find => replace
89D804C4 3C22 => 89D804C1 3C22
and
89D804C4 3C22 => 89D80455 3C22

In both cases, the CPU clings to obsolete AppleIntelCPUPowerManagement.kext

 

Are there any better ones?

Edited April 12, 2019 by yapan4

[apianti]

On 4/12/2019 at 12:49 PM, yapan4 said:

@apiantiThank you again.
I tested only two options in bootstrap find => replace
89D804C4 3C22 => 89D804C1 3C22
and
89D804C4 3C22 => 89D80455 3C22

In both cases, the CPU clings to obsolete AppleIntelCPUPowerManagement.kext

 

Are there any better ones?

 

Yeah, there may be, you'll have to look at how the bootstrap patch works in order to understand it and which model to choose. I have no idea which models are which, someone needs to disassemble the kernel, find the table, and determine which would be the best for those cpus. And that is expected since it should be using XCPM instead, the problem in that case is you have full throttle? You need freqency vector information in the model board-id plist that one script modifies.

 

EDIT: Part of my response was missing...?

 

EDIT2: Typos, lol.

Edited April 13, 2019 by apianti

[yapan4]

9 hours ago, apianti said:

EDIT: Part of my response was missing...?

Sorry, i still use google translate -to and -from english and I can not understand, miss, misunderstand something...

...but I do not want to take away your precious time

 

Went to study frequency vectors...

[apianti]

5 hours ago, yapan4 said:

Sorry, i still use google translate -to and -from english and I can not understand, miss, misunderstand something...

...but I do not want to take away your precious time

 

Went to study frequency vectors...

 

Oh, when I posted my reply the middle of my post was cut out, so there was like a sentence and a half missing. I was just listing the reason I edited the post. You need these two things to generate the SSDT and freqency vectors:

https://github.com/Piker-Alpha/ssdtPRGen.sh

https://github.com/Piker-Alpha/freqVectorsEdit.sh

[yapan4]

Only the results of trial run scripts:
freqVectorsEdit.sh passes 

ssdtPRGen.sh says "Unknown processor model..."

[apianti]

Okay, you can get around this by specifying your cpu with the -p parameter, like:

https://github.com/Piker-Alpha/ssdtPRGen.sh/blob/Beta/Data/Skylake.cfg#L28

./ssdtPRGen.sh -p W-2123

 

You can open an issue there and point out these lines and the format of your CPU's brand string being different so it doesn't extract the correct name.

https://github.com/Piker-Alpha/ssdtPRGen.sh/blob/Beta/ssdtPRGen.sh#L2803

[yapan4]

22 minutes ago, apianti said:

Okay, you can get around this by specifying your cpu with the -p parameter, like:

https://github.com/Piker-Alpha/ssdtPRGen.sh/blob/Beta/Data/Skylake.cfg#L28

./ssdtPRGen.sh -p W-2123

 

You can open an issue there and point out these lines and the format of your CPU's brand string being different so it doesn't extract the correct name.

https://github.com/Piker-Alpha/ssdtPRGen.sh/blob/Beta/ssdtPRGen.sh#L2803

I will do...

Some progress

Edited April 13, 2019 by yapan4

[apianti]

Look at the script readme and change the parameters you need. And let him know in your issue, with all these outcomes as well. To get the output from all the commands you can use:

command | tee -a file.txt

 

Edited April 13, 2019 by apianti

[yapan4]

2 hours ago, apianti said:

Look at the script readme and change the parameters you need. And let him know in your issue, with all these outcomes as well. To get the output from all the commands you can use:

command | tee -a file.txt

 

Not understood yet how to correct the script to see correctly processor type and iMacPro1,1 boardID, also confusing with commands order in help.

file.txt

[apianti]

No, I am pretty sure those are all part of the issue, as it should be making difference choices for those CPUs compared to the other Skylake CPUs. There is already an issue open for the cpu-type suggestion, I'm guessing what you have is correct if it says the correct CPU for you in about this mac. It looks like that other message is also incorrect. I think that SSDT should work.

[yapan4]

Hi. @obus

Some files for you

There is a terminal scanshot and a script folder from my home directory, hopefully help. Also there is sstd.aml generated by screept, I do not understand anything in the ACPI tables, maybe you will find something useful.

For @obus.zip

Edited April 14, 2019 by yapan4

[skyflying5]

Hi. I've read all

 

My situation is the cpu cannot change the frequence even I use the FakeCPUID “0506E4” and xcpm_kpg_cope path

 

My cpu is W-2150B motherboard is Supermicro X11srm-f C422

 

with or without FakeCPUID is not different for me. The CPU frequence always stay at 3.0G for all cores

 

I almost tried all you are said method, it make no difference

 

I'm confused

 

Please help me to solve the problems！

 

Ths！

 

Mac os is 10.13.6

Edited April 15, 2019 by skyflying5

[yapan4]

3 hours ago, skyflying5 said:

Hi. I've read all

 

My situation is the cpu cannot change the frequence even I use the FakeCPUID “0506E4” and xcpm_kpg_cope path

 

My cpu is W-2150B motherboard is Supermicro X11srm-f C422

 

with or without FakeCPUID is not different for me. The CPU frequence always stay at 3.0G for all cores

 

I almost tried all you are said method, it make no difference

 

I'm confused

 

Please help me to solve the problems！

 

Ths！

 

Mac os is 10.13.6

Is everything good in Windows and BIOS?

[hardcorehenry]

4 hours ago, skyflying5 said:

Hi. I've read all

 

My situation is the cpu cannot change the frequence even I use the FakeCPUID “0506E4” and xcpm_kpg_cope path

 

My cpu is W-2150B motherboard is Supermicro X11srm-f C422

 

with or without FakeCPUID is not different for me. The CPU frequence always stay at 3.0G for all cores

 

I almost tried all you are said method, it make no difference

 

I'm confused

 

Please help me to solve the problems！

 

Ths！

 

Mac os is 10.13.6

Have you tried CPUFriend.kext? It helped many people with too high frequencies of CPU, just follow the instructions.

[skyflying5]

2 hours ago, yapan4 said:

Is everything good in Windows and BIOS?

everything is perfect in my windows 10

 

I'm not sure about BIOS setting  whether is satisfied for the os or not

because my motherboard is not the same as Asus WS C422

I just can make it as same setting as possible

 

So，as you all see it cannot change the frequence at all

[skyflying5]

1 hour ago, hardcorehenry said:

Have you tried CPUFriend.kext? It helped many people with too high frequencies of CPU, just follow the instructions.

THs for you respond

I have the same CPU as the iMac Pro

It must be have someway easier than use the third part kext

 

In the booting log on the screen ，I already see the p-state generate successfully

But when I login it still the same frequence

[yapan4]

On 4/14/2019 at 5:16 AM, apianti said:

No, I am pretty sure those are all part of the issue, as it should be making difference choices for those CPUs compared to the other Skylake CPUs. There is already an issue open for the cpu-type suggestion, I'm guessing what you have is correct if it says the correct CPU for you in about this mac. It looks like that other message is also incorrect. I think that SSDT should work.

With beta-file(attached) generated by ssdtPRGen.sh and bootstrap_pach enabled no difference in macOS.

I dont known what to do next and I have to take a pause to additioal study ACPI, CPUPM, etc.

Thank you.

ssdt.aml

[hardcorehenry]

11 minutes ago, skyflying5 said:

THs for you respond

I have the same CPU as the iMac Pro 

It must be have someway easier than use the third part kext

 

In the booting log on the screen ，I already see the p-state generate successfully

But when I login it still the same frequence

I got problem with high constant

 

16 minutes ago, skyflying5 said:

THs for you respond

I have the same CPU as the iMac Pro 

It must be have someway easier than use the third part kext

 

In the booting log on the screen ，I already see the p-state generate successfully

But when I login it still the same frequence

I have different processor but had the same high constant frequence problem. I got rid of NullCPUxxx.kext and in my case pulgin type via config.plist didn't worked, so I put SSDT-XCPM.aml into clover/ACPI/patched and it solved my problems. You probably tried it, if not worth searching.

[yapan4]

24 minutes ago, hardcorehenry said:

I got problem with high constant

 

I have different processor but had the same high constant frequence problem. I got rid of NullCPUxxx.kext and in my case pulgin type via config.plist didn't worked, so I put SSDT-XCPM.aml into clover/ACPI/patched and it solved my problems. You probably tried it, if not worth searching.

Share please you worked SSDT-XCPM.aml .

Thank you.

[hardcorehenry]

20 minutes ago, yapan4 said:

Share please you worked SSDT-XCPM.aml .

Thank you.

You could find this here. But you don't need this since you generated your own SSDT it contains plugin-type inside. You could try generate "cf-frequency-data" by this instruction and paste into your SSDT, so your CPU could reach lower frequencies. Then build or download CPUFriend.kext.