Contribute
Register

X299 Big Sur Support

Status
Not open for further replies.
Okay ... it's little to complicated for me.
Are we sure that "CpuTscSync.kext" doesn't do the same thing ?
Or
How can we verified that "CpuTscSync.kext" isn't working properly or as "TSCAdjustReset.kext" is ?
Thanks
I wouldn't waste my time with that (humor on :)) and simply use TSCAdjustReset.kext, you can check on your IOReg the kext must be loaded at the end of CPXX/PRXX number and see if the value on the right side on IOReg by clicking on the arrow properties corresponds in Hex value to you CPU core number, and your system must be stable and not freezing with the proper kext.
 
I wouldn't waste my time with that (humor on :)) and simply use TSCAdjustReset.kext, you can check on your IOReg the kext must be loaded at the end of CPXX/PRXX number and see if the value on the right side on IOReg by clicking on the arrow properties corresponds in Hex value to you CPU core number, and your system must be stable and not freezing with the proper kext.

Im currently using CpuTscSync.kext and everything is working flawlessly (apart from my NVRAM, but different story).

Im also interested in this, my Geekbench Multicore scores are right up there in the top end of the range for my CPU model, I think very good scores because cooling is good and stays under 60c, so I've got no indication of any issue with performance or CPU threads not working correctly.

I guess the question is - are there specific advantages and disadvantages to either method?

Or it either works or it doesn't and it really doesn't matter which method you choose?
 
They both work, but TSCAdjustReset is specific to X299 and only needs to run its code once, on startup. Where CpuTscSync runs regularly, always making sure the TSCs are in sync across the cores. But on X299, the TSCs are already always are in sync - on X299 just one correction needs to be made to them all, which TSCAdjustReset does at startup. After that, it goes idle - it could even be unloaded, the Github page says (though I don't believe it's possible to unload running kexts any more as of Big Sur.)

So theoretically using TSCAdjustReset should be more efficient, saving a few clock cycles and having one less active kext. But it's probably such a small difference that it's not measurable, or certainly not by standard benchmarks.

CpuTscSync has the advantage that it's actively maintained by Acidanthera, making it as 'official' as anything can be for Hacks. Meaning it will definitely be updated and kept current over time, should any future compatibility changes be needed. We don't know if that will be the case for TSCAdjustReset, though it certainly runs fine for now.

I use TSCAdjustReset on the basis that if I can have fewer unnecessary instructions being executed, why not. But I really doubt there's any significant difference either way.
 
Last edited:
They both work, but TSCAdjustReset is specific to X299 and only needs to run its code once, on startup. Where CpuTscSync runs regularly, always making sure the TSCs are in sync across the cores. But on X299, the TSCs are already always are in sync - on X299 just one correction needs to be made to them all, which TSCAdjustReset does at startup. After that, it goes idle - it could even be unloaded, the Github page says (though I don't believe it's possible to unload running kexts any more as of Big Sur.)

So theoretically using TSCAdjustReset should be more efficient, saving a few clock cycles and having one less active kext. But it's probably such a small difference that it's not measurable, or certainly not by standard benchmarks.

CpuTscSync has the advantage that it's actively maintained by Acidanthera, making it as 'official' as anything can be for Hacks. Meaning it will definitely be updated and kept current over time, should any future compatibility changes be needed. We don't know if that will be the case for TSCAdjustReset, though it certainly runs fine for now.

I use TSCAdjustReset on the basis that if I can have fewer unnecessary instructions being executed, why not. But I really doubt there's any significant difference either way.
Thanks
 
Quick Questions for Big Sur users...

1) Disabling WhateverGreen (using MacPro 7,1 SMBIOS) now yields to no crashes as it did in Catalina. Using multiple monitors with no problems. DRM works in Safari (ie Amazon Prime, Netflix) but as usual not under Chrome (which is normal). Multi monitor also works.

2) EnableWriteUnprotector set to No and RebuildAppleMemoryMap set to Yes restarts the system during bootup. So keeping EnableWriteUnprotector set to Yes and RebuildAppleMemoryMap set to No fixes the issue. It seems that RebuildAppleMemoryMap succeeds EnableWriteUnprotector but doesn't seem to work for me.

3) Apple Menu > Shutdown restarts my system. Is there a way to fix this without using ACPI patches?
@izo1
The question is: our mobo does or doesn't support MAT tables (complying with the latest EDKII builds).
According to reports by Dortania Installation Guide, the solution is the following:
  • If your firmware supports MATs(2018+ firmwares):
    • EnableWriteUnprotector -> False
    • RebuildAppleMemoryMap -> True
    • SyncRuntimePermissions -> True
  • For older firmwares:
    • EnableWriteUnprotector -> True
    • RebuildAppleMemoryMap -> False
    • SyncRuntimePermissions -> False
In my config.plist I adopted the 2nd solution and it works, but we can try to search the better solution with the help of someone technically more skilled

Controversial is the setting of "SetupVirtualMap". I set as "true" ...
 
Last edited:
@izo1
The question is: our mobo does or doesn't support MAT tables (complying with the latest EDKII builds).
According to reports by Dortania Installation Guide, the solution is the following:
  • If your firmware supports MATs(2018+ firmwares):
    • EnableWriteUnprotector -> False
    • RebuildAppleMemoryMap -> True
    • SyncRuntimePermissions -> True
  • For older firmwares:
    • EnableWriteUnprotector -> True
    • RebuildAppleMemoryMap -> False
    • SyncRuntimePermissions -> False
In my config.plist I adopted the 2nd solution and it works, but we can try to search the better solution with the help of someone technically more skilled

Controversial is the setting of "SetupVirtualMap". I set as "true" ...

Good to know, thanks. Definitely using #2 on my end already which has no issues.

So I was able to fix the shutdown with the SSDT and the Patch from Dortania's guide. Surprisingly this issue started happening since Catalina and Mojave didn't have that issue.

Regarding the WG issue, I'm going to keep using it in Big Sur since the pink lines during the Apple logo are still there sometimes without it.
 
Quick Questions for Big Sur users...

1) Disabling WhateverGreen (using MacPro 7,1 SMBIOS) now yields to no crashes as it did in Catalina. Using multiple monitors with no problems. DRM works in Safari (ie Amazon Prime, Netflix) but as usual not under Chrome (which is normal). Multi monitor also works.

2) EnableWriteUnprotector set to No and RebuildAppleMemoryMap set to Yes restarts the system during bootup. So keeping EnableWriteUnprotector set to Yes and RebuildAppleMemoryMap set to No fixes the issue. It seems that RebuildAppleMemoryMap succeeds EnableWriteUnprotector but doesn't seem to work for me.

3) Apple Menu > Shutdown restarts my system. Is there a way to fix this without using ACPI patches?
For your problem 3, did you try setting "Wake to Lan" off in the BIOS?
 
For your problem 3, did you try setting "Wake to Lan" off in the BIOS?
Both ports have that as off.

Funnily enough, using Dortania's guide regarding this issue if I add the .aml and the patch, it still reboots during a shutdown. If I get rid of the .aml and just leave the patch in, it shuts down fine.

I have 2 PCI paths, PC00 and PC01 that both have separate USB controllers (PC00 is the onboard one and PC01 is a USB card).

I have tried 2 amls. It most likely has to do with the USB PCie card, but I need that for the front ports on the case.
 
Last edited:
Quick Questions for Big Sur users...

1) Disabling WhateverGreen (using MacPro 7,1 SMBIOS) now yields to no crashes as it did in Catalina. Using multiple monitors with no problems. DRM works in Safari (ie Amazon Prime, Netflix) but as usual not under Chrome (which is normal). Multi monitor also works.

2) EnableWriteUnprotector set to No and RebuildAppleMemoryMap set to Yes restarts the system during bootup. So keeping EnableWriteUnprotector set to Yes and RebuildAppleMemoryMap set to No fixes the issue. It seems that RebuildAppleMemoryMap succeeds EnableWriteUnprotector but doesn't seem to work for me.

3) Apple Menu > Shutdown restarts my system. Is there a way to fix this without using ACPI patches?
Do you have Serial Device off in BIOS?

I had a similar problem with shutdown - restarts and audio crackling before turned this off. Though I had big problems with XHCI handoff also in previous BIOS firmwares that got solved in the latest 3203 firmware, so not really sure if the restart problem was also w. older firmware.

Crackling audio was def. the serial device as I can easily reproduce that problem with a toggle.

  • If your firmware supports MATs(2018+ firmwares):
    • EnableWriteUnprotector -> False
    • RebuildAppleMemoryMap -> True
    • SyncRuntimePermissions -> True
  • For older firmwares:
    • EnableWriteUnprotector -> True
    • RebuildAppleMemoryMap -> False
    • SyncRuntimePermissions -> False

I have first and been smooth sailing with that. Every now and then (randomly) boot results in a underline glyph. Will try the second method at some point.
 
Do you have Serial Device off in BIOS?

I had a similar problem with shutdown - restarts and audio crackling before turned this off. Though I had big problems with XHCI handoff also in previous BIOS firmwares that got solved in the latest 3203 firmware, so not really sure if the restart problem was also w. older firmware.

Crackling audio was def. the serial device as I can easily reproduce that problem with a toggle.



I have first and been smooth sailing with that. Every now and then (randomly) boot results in a underline glyph. Will try the second method at some point.

Yeah I have Serial off, which funnily enough always gets enabled after restoring with a .cmo file (BIOS settings).

Never had audio crackling issue here with Sage 10.

Regarding the underline glyph I have that issue too sometimes, curious as to why. But I do use #2 because #1 doesn't let me boot.
 
Status
Not open for further replies.
Back
Top