Contribute
Register

Gigabyte Z390 M Gaming build with working NVRAM

Hi @pastrychef, I have 1TB ssd samsung 970 PRO and the boot it's some slow. Should I use the NVMEFix.kext? How can I tell if I have the max speed working on boot? Thanks!
 
Hi @pastrychef, I have 1TB ssd samsung 970 PRO and the boot it's some slow. Should I use the NVMEFix.kext? How can I tell if I have the max speed working on boot? Thanks!

I have never tried NVMEFix.kext.

I don't know of any good fixes for the slow boot issue on Samsung NVMe SSDs.
 
The best I've been able to glean, NVMEfix is a workaround for excessive NVMe power consumption for some laptops. I guess we should read the code...

Late versions of OpenCore (0.8.0) includes SetApfsTrimTimeout to help with boot delays (I have not tested this with my 980 Pro which delays — I ended up running a WD 750 which doesn't suffer). See note 2 regarding macOS 12...

From the Opencore Configuration Guide (search the web for PDF):

SetApfsTrimTimeout
Type: plist integer
Failsafe: -1
Requirement: 10.14 (not required for older)
Description: Set trim timeout in microseconds for APFS filesystems on SSDs.
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.
 
For those interested, I had to lose my Broadcom PCIe card so I just installed the

GIGABYTE GC-CI22M_A CNVi WiFi Wireless-AC Upgrade kit​

and after using the latest intel/WiFi kexts (and enabling HS014 in the usb map) I have terrific WiFi and Bluetooth functionality — a first!

I’m sure Handoff and sidecar wont work but I haven’t tried.

I’m on OC 080 and Mac OS 12.4 btw.

Cheers,
J
 
As delivery of my Mac Studio gets closer, I have given away my Gigabyte Z390 M Gaming build to a friend.
Thanks for all your support, Pastrychef. This means that you will no longer post updates of EFI folders. Correct?

Cheers!
 
Thanks for all your support, Pastrychef. This means that you will no longer post updates of EFI folders. Correct?

Cheers!

I can update but no longer have a machine to test... I'll try my best but will need input from you guys to tell me if something is broken.
 
I can update but no longer have a machine to test... I'll try my best but will need input from you guys to tell me if something is broken.
At the risk of absolving @pastrychef from ALL responsibilities I think the best method moving forward is through @Inqnuam’s glorious HackinDROM standalone app, which truly automates all of the leg-work, guess-work and just plain old work in updating EFI folders moving forward (or at least until he decides he’s leaving for the Dark Side, too).
 
At the risk of absolving @pastrychef from ALL responsibilities I think the best method moving forward is through @Inqnuam’s glorious HackinDROM standalone app, which truly automates all of the leg-work, guess-work and just plain old work in updating EFI folders moving forward (or at least until he decides he’s leaving for the Dark Side, too).

If everything is working, it's not hard to keep EFIs updated. vit9696 makes things easy for us by documenting changes very well. Just look at the comments with each new version of OpenCore. For example, on version 0.8.0, we see that "ForceAquantiaEthernet" was added. So, we just need to add that to our config.plists.

Screen Shot 2022-05-24 at 5.18.10 AM.png
 
Chef would you briefly describe your process for updating Clover, too? Do you like just take a sample EFI folder and replace with new kexts and your updated config.plist? Which of these would you use? Thanks for everything. OMG!
 

Attachments

  • 91A0779B-D39D-489C-B585-686A5FC939B1.jpeg
    91A0779B-D39D-489C-B585-686A5FC939B1.jpeg
    88.3 KB · Views: 29
Hi folks,

I'm running Big Sur and OC 0.7.4, very stable since about last October which was when I last updated OC. I thought I'd try the OC 0.8.0 tonight.

Ran the EFI on a USB stick with the config.plist file updated with my serials (used Opencore configurator for the first time). However when it got to the Apple logo after the OC bootloader screen (selecting my Big Sur install), it crashed and went back to the Bios screen. I tried again, reset nvram, but no luck.

FYI, I'm still running BIOS F9g as it's been fine so far and I've not needed to go into Bios for 8 months as everything has been fine. The unlock thingy in bios was done before so that's not the issue.

No idea how 0.7.4 works flawlessly (as has ever previous OC version I've used, but 0.8.0 doesn't. I was going to update to Monterey, hence why I wanted to update to latest OC version first.


Any thoughts appreciated.
 
Back
Top