MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[PeterHolbrook]

Is there a known timeline for the release of OC 0.8.0?

 

[cdf]

Is there a known timeline for the release of OC 0.8.0?

It's been delayed by another week.

2022.04 release planning · Issue #1969 · acidanthera/bugtracker

OpenCore 0.8.0 CpuTscSync 1.0.8 AppleALC 1.7.1 FeatureUnlock 1.0.8 CPUFriend 1.2.5

github.com

 

[EvilMonk]

Quick question… we need a kext in opencore to enable SMP systems with Mac OS now on dual cpu Mac Pro systems right?

 

[JeDiGM]

Don't really matter if it's your boot drive or not, TRIM runs at boot time is for all disks that have it enabled.

When I install my SM951-AHCI with HighSierra in my Mac Pro, the boot times of my main disk, a 970 PRO with BigSur jump to over 3 minutes to arrive at the login screen and even more for my PM961 with Monterey.

@tsialex I'm not sure I'm completely understanding this. Does this mean that the only time Samsung SSDs run trim cleanup is at boot time on cMP unless over-provisioning is configured?

 

[tsialex]

@tsialex I'm not sure I'm completely understanding this. Does this mean that the only time Samsung SSDs run trim cleanup is at boot time on cMP unless over-provisioning is configured?

TRIM with APFS in reality are various processes and what is affecting us with Samsung SSDs and others is that when the macOS kernel instructs the SSD controller that a list of sectors that were deallocated by the APFS driver and marked for erase, the operation times-out. This happens at boot time, then the controller does all the erase later in the background.

See the documentation of SetApfsTrimTimeout:

The APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.
Depending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.
On several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.
One way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Setting this option to a high value, such as 4294967295 ensures that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be mostly disabled by setting a very low timeout value, while 0 entirely disables it. Refer to this article for details.
Note: The failsafe value -1 indicates that this patch will not be applied, such that apfs.kext will remain untouched.
Note 2: On macOS 12.0 and above, it is no longer possible to specify trim timeout. However, it can be disabled by setting 0.
Note 3: Trim operations are only affected at booting phase when the startup volume is mounted. Either specifying timeout, or completely disabling trim with 0, will not affect normal macOS running.

 

[6DecadesLater]

TRIM with APFS in reality are various processes and what is affecting us with Samsung SSDs and others is that when the macOS kernel instructs the SSD controller that a list of sectors that were deallocated by the APFS driver and marked for erase, the operation times-out. This happens at boot time, then the controller does all the erase later in the background.

See the documentation of SetApfsTrimTimeout:

"Note 2: On macOS 12.0 and above, it is no longer possible to specify trim timeout. However, it can be disabled by setting 0."
If I understand then, setting SetApfsTrimTimeout to anything other than 0 in 12.0 or greater has no effect? Per your suggestion, I set it to 4294967295. Booting does seem to be quite a bit faster but I am confused by the conflicting information stating that only setting to 0 has an effect.

And is over-provisioning an alternative when SetApfsTrimTimeout=0?

 

[tsialex]

"Note 2: On macOS 12.0 and above, it is no longer possible to specify trim timeout. However, it can be disabled by setting 0."
If I understand then, setting SetApfsTrimTimeout to anything other than 0 in 12.0 or greater has no effect? Per your suggestion, I set it to 4294967295. Booting does seem to be quite a bit faster but I am confused by the conflicting information stating that only setting to 0 has an effect.

And is over-provisioning an alternative when SetApfsTrimTimeout=0?

I'm not the best person to answer about Monterey and SetApfsTrimTimeout since I'm still running 11.6.5 as my main/work disk, a 970 PRO, the extended SetApfsTrimTimeout still works perfectly fine and it's the only thing that solves the slowdown with my SM951-AHCI and PM961 blades. My Monterey test blade is a XPG S40G that seems to work fine with TRIM - it's a recently bought one and I don't really know how it will behave after several cycles of being full/erased.

Later this year, when I'm gonna move to Monterey as a main/work disk, if I'm still running with the same blades, I'll give-up and change to over-provisioning.

 

[6DecadesLater]

my boot drive is disk0
/dev/disk0 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *2.0 TB disk0

1: EFI ⁨EFI⁩ 209.7 MB disk0s1

2: Apple_APFS ⁨Container disk12⁩ 2.0 TB disk0s2

I try to resize but get message
Started APFS operation

Aligning shrink delta to 186 189 180 928 bytes and targeting a new physical store size of 1 813 999 996 928 bytes

Determined the minimum size for the targeted physical store of this APFS Container to be 1 984 006 455 296 bytes

Error: -69521: Your APFS Container resize request is below the APFS-system-imposed minimal container size (perhaps caused by APFS Snapshot usage by Time Machine)

In a terminal: (Replace Monterey with your volume name)

diskutil ap listSnapshots /Volumes/Monterey

You will see something like
Snapshot for disk1s4s1 (1 found)
|
+-- 40BBC8EE-A2CA-43A7-9C57-C1C2B99C2919
Name: com.apple.os.update-D296176C9F1447A402795DE19045A404D91C61D21590F8E018EB80C949FBD899
XID: 11855440 (Will root to (boot from) this snapshot)
Purgeable: No
NOTE: This snapshot limits the minimum size of APFS Container disk1

Then do (again, replace Monterey with your volume name). This will delete the snapshot
tmutil deletelocalsnapshots /Volumes/Monterey

Then try resizing again

 

[6DecadesLater]

I'm not the best person to answer about Monterey and SetApfsTrimTimeout since I'm still running 11.6.5 as my main/work disk, a 970 PRO, the extended SetApfsTrimTimeout still works perfectly fine and it's the only thing that solves the slowdown with my SM951-AHCI and PM961 blades. My Monterey test blade is a XPG S40G that seems to work fine with TRIM - it's a recently bought one and I don't really know how it will behave after several cycles of being full/erased.

Later this year, when I'm gonna move to Monterey as a main/work disk, if I'm still running with the same blades, I'll give-up and change to over-provisioning.

Thanks - still confused on one point. With over-provisioning in place, would you set SetApfsTrimTimeout=0?

 

[tsialex]

Thanks - still confused on one point. With over-provisioning in place, would you set SetApfsTrimTimeout=0?

Yes, after you disable TRIM the SSD controller will manage garbage collection by itself.

 

[JeDiGM]

Yes, after you disable TRIM the SSD controller will manage garbage collection by itself.

Thanks for information @tsialex. Very helpful, as always. After reading your response I'm wondering, would it be good practice to restart the machine every so often to push the cleanup process to occur? What happens if the boot process is taking too long for someone and an opencore user gets impatient and forces a reboot during the trim process or the power cuts out in the middle of it? Does is resume on next boot?

What do you do with your machine and what would you recommend users do to maintain and preserve the life of their Samsung drives in macOS using APFS or any other formatted drives?

 

[Dayo]

I am confused by the conflicting information

Not sure if it is a factor, and I don't know much about TRIM details, but some conflicting information may have come from there being two errors in the documentation for SetApfsTrimTimeout up to the v0.7.9 release, which was only recently corrected and will appear as from v0.8.0.

Firstly, the documentation had suggested that TRIM operations/settings under SetApfsTrimTimeout propagate to when the OS is running. This has been changed to somewhat clarify that it only affects the boot stage.

Secondly, the documentation had stated that setting SetApfsTrimTimeout to -1 was the same as, a shorthand form of, setting the maximum value of 4294967295. It is indeed the case that this shorthand form can be used in many places in the config. See posts below from earlier in this thread:

OpenCore on the Mac Pro

Yes, zero is wrong as it is has a specific connection as on cMP7,1. Btw, you can use "-1" instead of "4294967295". It applies for any "0xF ... F" value. Are you still able to with 0.6.7? El Capitan is not booting via OC on cMP3,1. You can boot it natively of course but strange that it...

forums.macrumors.com

OpenCore on the Mac Pro

-1 is INT32 signed (see SetApfsTrimTimeout), 4294967295 is unsigned. I'm confused, the documentation states clearly to use the 0xFFFFFFFF value but it does not says if we should use signed or unsigned INT32: Which one do we use @cdf, I need that calculator explanation. I opened #1543.

forums.macrumors.com

OpenCore on the Mac Pro

4294967295 is more explicit, but -1 is much easier. We should go with the latter.

forums.macrumors.com

So yes, -1 is a shorthand form of 4294967295 but if you pay attention to the first post above, It applies for any "0xF ... F" value (Max Hex Values) which SetApfsTrimTimeout does not use (it takes and uses integers). This has now been corrected in the documentation although the wording still leaves much to be desired.

There are three (3) settings for SetApfsTrimTimeout so to speak:

1. SetApfsTrimTimeout = -1 (failsafe value)
   • OpenCore does not change anything regarding TRIM
   • It is not clear what exactly happens regarding TRIM in this case
     • Presumably, whatever is set in the OS will happen
2. SetApfsTrimTimeout = 0
   • OpenCore explictly disables TRIM while booting
   • The OS does whatever it is set to do after boot
3. SetApfsTrimTimeout = 1 to 4294967295
   • OpenCore explictly changes the TRIM timeout from a default value to the set value while booting
     • It is not clear if this also means OpenCore swiches it ON when it is otherwise OFF
   • The OS does whatever it is set to do after boot
   • NB: The boot time TRIM timeout cannot be changed/set as of MacOS 12.0
     • It is not clear if there is even still a default in MacOS 12.0 and later

Again, not sure if this is a factor in there being apparent conflicting statements, but hope it sheds some light all the same.

 

[hwojtek]

Quick question… we need a kext in opencore to enable SMP systems with Mac OS now on dual cpu Mac Pro systems right?

No, we need a kext to override stock energy management in dual CPU Mac Pro systems. It's called "AppleMCEReporterDisabler.kext":

<key>Kernel</key>
<dict>
<key>Add</key>
<array>
⋮
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>BundlePath</key>
<string>AppleMCEReporterDisabler.kext</string>
<key>Comment</key>
<string>Dual-processor workaround</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string></string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>19.0.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
</array>

 

[tsialex]

Thanks for information @tsialex. Very helpful, as always. After reading your response I'm wondering, would it be good practice to restart the machine every so often to push the cleanup process to occur?

Since the APFS TRIM clean-up happens at boot-time, yes.

What happens if the boot process is taking too long for someone and an opencore user gets impatient and forces a reboot during the trim process or the power cuts out in the middle of it?

There are reports that you can get the blade controller in a limbo state, you shouldn't do it.

Does is resume on next boot?

You shouldn't risk messing with the SSD controller, also doing it causes flash wear since lower blocks are trimmed again.

What do you do with your machine and what would you recommend users do to maintain and preserve the life of their Samsung drives in macOS using APFS or any other formatted drives?

I'm using SetApfsTrimTimeout = 4294967295, takes a minute or two more to boot - no problem for me at all, since I'm not booting multiple times per day and it's a very worthy trade-off. The years of slowdowns were so much worse.

 

[EvilMonk]

No, we need a kext to override stock energy management in dual CPU Mac Pro systems. It's called "AppleMCEReporterDisabler.kext":

<key>Kernel</key>
<dict>
<key>Add</key>
<array>
⋮
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>BundlePath</key>
<string>AppleMCEReporterDisabler.kext</string>
<key>Comment</key>
<string>Dual-processor workaround</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string></string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>19.0.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
</array>

Thank you, I’m trying to wonder why my dual CPU x5690 will export HEVC for the same movie at different speeds and I think I found it.

 

[hwojtek]

Thank you, I’m trying to wonder why my dual CPU x5690 will export HEVC for the same movie at different speeds and I think I found it.

Once you go GPU encoding, you will not come back

 

[Bmju]

So yes, -1 is a shorthand form of 4294967295 but if you pay attention to the first post above, It applies for any "0xF ... F" value (Max Hex Values) which SetApfsTrimTimeout does not use (it takes and uses integers). This has now been corrected in the documentation although the wording still leaves much to be desired.

The issue about -1 is whether the value is a plist integer (which is 64 bit), e.g. SetApfsTrimTimeout, or a plist integer, 32-bit, e.g. PlatformFeature. The difference between the two is not about the plist, but about what the value gets put into in OpenCore as the plist is read. 4294967295 is -1 only for a 32-bit int, ofc (4,294,967,295 = 0xFFFFFFFF).

It also doesn't say in the docs (but it is warned about by ocvalidate), but when the 64 bit SetApfsTrimTimeout value is positive, it gets cast to 32-bit before being used, therefore 4294967295 is also in fact the max. positive value you can sanely set (higher values will wrap around, and will be reported by ocvalidate).

 

[dub*man]

Hi all - my 5.1 with NVME drive self updated and got stuck in a boot loop. I followed the instructions listed and my situation has regressed! Now I don’t get the apple logo before it gives up.

Any advice on what I could do to get my machine up and running again?

 

[tsialex]

Hi all - my 5.1 with NVME drive self updated and got stuck in a boot loop. I followed the instructions listed and my situation has regressed! Now I don’t get the apple logo before it gives up.

Any advice on what I could do to get my machine up and running again?

If you remove your NVMe blade, can you boot your Mojave rescue disk or a createinstallmedia USB installer of Mojave/HighSierra?

 

[dub*man]

Yes - I can boot via USB to Mojave on a rescue disk

 

[tsialex]

Yes - I can boot via USB to Mojave on a rescue disk

Ok, since you can still boot Mojave, you can diagnose your NVRAM - 12.3/12.3.1 boot loops can cause havoc inside the NVRAM. You should start flashing back your BootROM backup dump before anything.

 

[dub*man]

Dumped and backed up - looks healthy. Free space is at 46000! So the machine isn’t dead

 

[jvlfilms]

Hey all, I recently did Pixlas mod and upgraded my RX 580 to a XFX Vega 64 I got on eBay. I use Martin's OC package.

Everything is going fine but when I plug in with DP, I don't get a boot screen. I tried both BIOS modes and the same thing on all DisplayPorts. The system boots fine and shows full hardware acceleration in VideoProc in Monterey/Mojave but won't display a boot screen. Except...

When I plug into HDMI, I get the boot picker! Has anyone encountered this before? I did a quick search of the forums but nothing came up.

 

[trifero]

Hey all, I recently did Pixlas mod and upgraded my RX 580 to a XFX Vega 64 I got on eBay. I use Martin's OC package.

Everything is going fine but when I plug in with DP, I don't get a boot screen. I tried both BIOS modes and the same thing on all DisplayPorts. The system boots fine and shows full hardware acceleration in VideoProc in Monterey/Mojave but won't display a boot screen. Except...

When I plug into HDMI, I get the boot picker! Has anyone encountered this before? I did a quick search of the forums but nothing came up.

It´s not flashed for mac. You wont see the boot screen in DP´s.

 

[jvlfilms]

It´s not flashed for mac. You wont see the boot screen in DP´s.

Hey thanks for responding! Wouldn't I get boot screens with both DisplayPort and HDMI if I use OpenCore? That's how it works with my Sapphire Pulse RX 580 and I am able to get the picker from both HDMI/DP.

To be clear, by "boot screen" I mean the boot picker, not the original factory boot screen that you get from running an original ATI card.