Contribute
Register

How to build your own iMac Pro [Successful Build/Extended Guide]

Status
Not open for further replies.
One question about the Gigabyte BIOS settings.
In B2-Initial Gigabyte BIOS configuration you write under 2) f : Package C State limit : enabled.
In the current F7 BIOS the options under Package C State limit are: C0/C1, C2, C6, C6 (Retention) state, No Limit and Auto. The option “enabled” is not available. Which option would you recommend?
 

Attachments

  • 6693BBD4-65CE-4EE4-991C-EFBBDBA2429E.jpeg
    6693BBD4-65CE-4EE4-991C-EFBBDBA2429E.jpeg
    2.9 MB · Views: 81
0x67 is any the default value I use.

I have no time for tests, sorry... You suggested to use Clover's OsxAptioFixDrv.efi, so please also verify that your proposal and suggestion is stable. Thanks!
I did. It is rock solid - never once fails to allocate during the installation process or after. This seems to be a feature of the X99 and X299 platforms - the UEFI on these boards fragments the memory allocation for device drivers for some reason.
It is described here and here. Yes - I have read all about version 2 and free2000 as you will see from the second linked URL. What I am reporting is that it is the fix for the SIP issue that appears to cause the frequent allocation failures using version free2000 (for me it was about 4 out of 5 times). As I said above, the only issue I have had using the original driver after many reboots (manually initiated) without a problem is that you cannot set CsrActiveConfig to any value other than 0x67 - which for me is an issue but for others is not. To install some software (eg Nvidia Web Driver) requires SIP to be enabled to prevent incorrect permissions being set on KEXTs.

I regret but I also have to correct your above statements. Up to now, Clover's OsxAptioFixDrv.efi erroneously relocated memory, wich indeed resulted in frequent reboots of the system!
Doesn't happen for me on the hardware in my sig.
If you carefully watch the Clover Install Customisation Options, you will see that Clover also offers a OSXLowMemFixDrv-64.efi, which one could install to fix the Low Memory Errors of OsxAptioFixDrv.efi! Unfortunately, OSXLowMemFixDrv-64.efi did not work satisfactorily at all so far!
I'm quite familiar with all these options and their effects. I think your info is out of date.

That's why I used the OsxAptioFix2Drv-free2000.efi instead, which just shows occasionally some memory relocation error at at the very initial boot step, however which else behaves absolutely stable!

That's the reality, which unfortunately is at odd with your theory. If you can prove by stable results that I am wrong, I will be more than happy!
What I am suggesting is that, as long as you are happy with leaving CsrActiveConfig set to 0x67 then the original OsxAptioFixDrv.efi would appear to be much more reliable than the later versions - at least in my own use so far on High Sierra on X299. So it may be simpler to use it for the initial installation and setup for people who are having major issues with device memory allocation - note that this is a function of how many devices you have enabled in your system, such as SATA controllers, disk arrays etc. While it may not be an issue for you, for some with more complex hardware that cannot be avoided (like my internal SATA RAID arrays) the later versions simply don't work.

So, as I suggested to someone a few posts back - if you are having issues with OsxAptioFix2Drv-free2000.efi, give the original OsxAptioFixDrv.efi from Clover 4233 a try. It may get you past the issue you are having, after which you can finish your setup and change it to whatever works best.
 
This is after booting without any USB kext? I mean, this is your OS X XHC USB emergency configuration?

Looks really unexpected! I have never seen such configuration...
I think all 12 of the USB ports on the R6E are 3.1.

Nice board by the way but a bit rich here in Australia. Cheapest R6E here is $1499 - more than double the price of the Prime X299 Deluxe.
 
Last edited:
  • Like
Reactions: kgp
Thanks for the correction! Stupid Typo! Corrected!
FINALLY Got my rig working! :headbang::headbang: I am not sure what exactly happened but I think this typo is what broke my installer. I can't explain it but once I recreated the install disk with "--nointeraction" everything started working like Magic! Very frustrating but I am glad everything is working as KGP promised. Thanks again for all your help!
 
I did. It is rock solid - never once fails to allocate during the installation process or after. This seems to be a feature of the X99 and X299 platforms - the UEFI on these boards fragments the memory allocation for device drivers for some reason.
It is described here and here. Yes - I have read all about version 2 and free2000 as you will see from the second linked URL. What I am reporting is that it is the fix for the SIP issue that appears to cause the frequent allocation failures using version free2000 (for me it was about 4 out of 5 times). As I said above, the only issue I have had using the original driver after many reboots (manually initiated) without a problem is that you cannot set CsrActiveConfig to any value other than 0x67 - which for me is an issue but for others is not. To install some software (eg Nvidia Web Driver) requires SIP to be enabled to prevent incorrect permissions being set on KEXTs.


Doesn't happen for me on the hardware in my sig.

I'm quite familiar with all these options and their effects. I think your info is out of date.


What I am suggesting is that, as long as you are happy with leaving CsrActiveConfig set to 0x67 then the original OsxAptioFixDrv.efi would appear to be much more reliable than the later versions - at least in my own use so far on High Sierra on X299. So it may be simpler to use it for the initial installation and setup for people who are having major issues with device memory allocation - note that this is a function of how many devices you have enabled in your system, such as SATA controllers, disk arrays etc. While it may not be an issue for you, for some with more complex hardware that cannot be avoided (like my internal SATA RAID arrays) the later versions simply don't work.

So, as I suggested to someone a few posts back - if you are having issues with OsxAptioFix2Drv-free2000.efi, give the original OsxAptioFixDrv.efi from Clover 4233 a try. It may get you past the issue you are having, after which you can finish your setup and change it to whatever works best.

O.k. to finish the entire theoretical discussion, I will test the longterm system stability of Clover's OsxAptioFixDrv.efi and report back with a new EFI-Folder in case that it works! :thumbup: The new EFI-Folder also shall implement Clover_v2.4k_r4233...

Cheers,

KGP
 
FINALLY Got my rig working! :headbang::headbang: I am not sure what exactly happened but I think this typo is what broke my installer. I can't explain it but once I recreated the install disk with "--nointeraction" everything started working like Magic! Very frustrating but I am glad everything is working as KGP promised. Thanks again for all your help!

Yupppppieeee :headbang::headbang::headbang::headbang::headbang::headbang:

It was @dwhitla who detected the bug! :thumbup::thumbup::thumbup::thumbup::thumbup::thumbup:
 
One question about the Gigabyte BIOS settings.
In B2-Initial Gigabyte BIOS configuration you write under 2) f : Package C State limit : enabled.
In the current F7 BIOS the options under Package C State limit are: C0/C1, C2, C6, C6 (Retention) state, No Limit and Auto. The option “enabled” is not available. Which option would you recommend?

Well the option "C6(non retention) state" seems not available ... That would be the correct one! I guess the equivalent BIOS setting on the Gigabyte X299 AORUS Gaming 7 might be simply "C6" . Can you give it a try and report back?

Cheers,

KGP
 
Last edited:
Excellent news my friends!

With Clover_v2.4k_r4233 , for the first time ever, one can directly use Clover's OsxAptioFixDrv-64.efi in /EFI/CLOVER/drivers64UEFI/ to obtain a fully functional and fully stable system. Many thanks to @dwhitla for his excellent advice and notification!

Earlier versions of OsxAptioFixDrv-64.efi resulted in unstable system performance and random reboots. Over the years, I therefore previously always employed the OsxAptioFix2Drv-free2000.efi workaround in /EFI/CLOVER/drivers64UEFI/, which now has become totally obsolete! The latter workaround however occasionally resulted in memory allocation errors at the very initial boot step, while during system operation, OsxAptioFix2Drv-free2000.efi however always yielded a very stable and fully functional MacOS System.

In any case, with the current removal of OsxAptioFix2Drv-free2000.efi, also the memory allocation errors at boot totally vanished. The Skylake-X/X299 System no shows a brilliant performance during both boot and system operation!

Skylake-X/X299 macOS High Sierra 10.13 Desktop Guide updated in consequence.

New EFI-Folder attached at the end of the originating post/guide and here below!

EFI-Folder modifications:
  • Implementation of Clover_v2.4k_r4233
  • Removal of OsxAptioFix2Drv-free2000.efi from /EFI/CLOVER/drivers64UEFI/
  • Adding of OsxAptioFixDrv-64.efi (Clover_v2.4k_r4233) to /EFI/CLOVER/drivers64UEFI/
Guide-Modifications:
  • Respective parts of the guide have been updated correspondingly.

Enjoy and have fun!

kgp.png
 

Attachments

  • EFI-X299-10.13-Final-Release-031017.zip
    32.7 MB · Views: 166
Status
Not open for further replies.
Back
Top