Long 15 Second "Pause" During Boot

[ski4evr]

OpenCore 0.6.7
Big Sur 11.2.3 (20D91)
GA-Z97n-WiFi
i7 4790K LGA1150 Haswell
HD 4600
BCM94352HMB (Card: Half Size mini-PCIe; Network Slot on board)

During boot, I get a long 15 second pause with the apple progress bar after a few seconds of movement. Then, the screen goes black and the apple logo and progress bar reappear with the progress bar moving fast. Quickly, the desktop appears. I've lived with the boot pause for a while, now. It's starting to really bug me. With verbose, the long pause happens here:

After sitting at the above screen for 15 seconds, the verbose screen starts moving here:

The screen goes blank. Apple logo with a fast moving progress bar appears. And the desktop appears in very short order.

Attached is my EFI folder with the serial number removed.

Any thoughts?

 

[Edhawk]

Not sure about the 15 second delay, could be caused by any number of issues.

Possibly one of these issues.

1. As you are using a USB-Map.kext you don't need and shouldn't be using USBInjectAll.kext at the same time, even if disabled in the config.plist (saw that after I wrote the first part!).
2. The SSDT-EC.aml and SSDT-PLUG.aml you are using are generic catch all tables, with multiple entries in both SSDT's.
   1. You would be better served creating custom SSDT's specifically for your system using your Systems DSDT.aml and Corpnewt's SSDTTime python script - https://github.com/corpnewt/SSDTTime.
   2. Both of these SSDT's are known to be slower to load than a custom SSDT.
3. You are lacking a number of common ACPI rename patches, that help a Haswell system work better with macOS. I would suggest you have a read and look at the EFI attached to this Monterey guide for a similar Haswell system - https://www.tonymacx86.com/threads/guide-haswell-system-macos-monterey-12-0-1-oc-0-7-5.317413/ Specifically the patches and SSDT's used in this OC 0.7.5 setup.

 

[hannibal1969]

I think its because of SSD trim. This is there already for a long time since about APFS or so. There is a way to tune macos in opencore how much time it may take during boot. So you can tune it to a shorter time but then you will probably end up in fragmented or untrimmed ssd after a while… so i leave it the standard setting. Also the type and brand of the ssd can cause issues. Some are not supported trim correctly in macOS. See: https://dortania.github.io/Anti-Hackintosh-Buyers-Guide/Storage.html

 

[ski4evr]

The SSDT-EC.aml and SSDT-PLUG.aml you are using are generic catch all tables, with multiple entries in both SSDT's.

1. You would be better served creating custom SSDT's specifically for your system using your Systems DSDT.aml and Corpnewt's SSDTTime python script - https://github.com/corpnewt/SSDTTime.

@Edhawk, as you point out, I only have two SSDT’s. Your build has eight. Are all eight of yours generated using SSDTTime? And what to they do?

Edhawk	ski4evr
SSDT-EC-USBX	SSDT-EC
SSDT-EHCX_OFF	SSDT-PLUG
SSDT-Fix-USB-Shutdown
SSDT-HPET
SSDT-PLUG
SSDT-SBUS-MCHC
SSDT-XOSI
SSDT-XWAK

​

You mentioned that my two generic ones contain multiple entries. Does that mean the generic ones contain some of your eight, implying yours are the bare minimum discrete SSDT’s required for the Z87/97 Haswell systems that we have?

 

[Edhawk]

No, Just SSDT-EC-USBX.aml, SSDT-HPET.aml and SSDT-PLUG.aml were generated using SSDTTime and my system's DSDT.aml.

The others were collected from VioletDragon's GitHub 9-Series repository https://github.com/VoiletDragon

The SSDT-XOSI.aml was provided by Rehabman - https://github.com/RehabMan/OS-X-Clover-Laptop-Config/tree/master/hotpatch

You need to remember that these three SSDT's require complimentary ACPI rename patches for them to work.

• SSDT-HPET.aml - three patches
• SSDT-XOSI.aml - single patch
• SSDT-XWAK.aml - single patch

The patches are in the OC config.plist.

 

[hannibal1969]

Search on SetApfsTrimTimeout

Samsung 970 EVO NVMe + 860 EVO SATA (TRIM NOT WORKING?)

Hello guys and thanks in advance for any help, I've had this build for a year (Clover, Catalina 10.15.4, Gigabyte z390 Designare, i9 9900k, RX580) but recently was made familiar with the Trim bug on Samsungs. My 970 Evo NVMe is running my system. It's the latest revision (2B2QEXM7) and is...

www.tonymacx86.com

Quite a lot of SSDs are prone to be incompatible with macOS. Use opencore SetApfsTrimTimeout.

I read also somewhere someone making a backup with CCC and restore it will speed up the boot. (Probably due a manual Trim which will happen if you format to 0s). I think it has to do with Trim not with SSDts.

 

[ski4evr]

Quite a lot of SSDs are prone to be incompatible with macOS. Use opencore SetApfsTrimTimeout.

@hannibal1969, I don't think my boot delay is associated with the SSD Trim incompatibility issue people have been experiencing with Monterey and certain NVMe SSDs. I'm still using Big Sur on this build and I'm using a Samsung EVO Sata SSD. I don't see any Trim related messages in the verbose log.

 

[ski4evr]

No, Just SSDT-EC-USBX.aml, SSDT-HPET.aml and SSDT-PLUG.aml were generated using SSDTTime and my system's DSDT.aml.

The others were collected from VioletDragon's GitHub 9-Series repository https://github.com/VoiletDragon

The SSDT-XOSI.aml was provided by Rehabman - https://github.com/RehabMan/OS-X-Clover-Laptop-Config/tree/master/hotpatch

You need to remember that these three SSDT's require complimentary ACPI rename patches for them to work.

• SSDT-HPET.aml - three patches
• SSDT-XOSI.aml - single patch
• SSDT-XWAK.aml - single patch

The patches are in the OC config.plist.

I've been using the generic SSDT's since switching over to OpenCore. I'll look at using SSDTTime tonight. I'll update my progress this weekend.

 

[hannibal1969]

@hannibal1969, I don't think my boot delay is associated with the SSD Trim incompatibility issue people have been experiencing with Monterey and certain NVMe SSDs. I'm still using Big Sur on this build and I'm using a Samsung EVO Sata SSD. I don't see any Trim related messages in the verbose log.

This issue is also with Big Sur. I know that there are Samsung EVOs with a trim issue. You wont see Trim messages. The thing is that the trim process initiated every time macOS boots. This process takes time and if you use an incompatible nvme it takes much longer. There is a list with NVMEs. If you have time clone it to a regular SSD you maybe have as spare.

You can try also: https://github.com/acidanthera/NVMeFix

 

[ski4evr]

No, Just SSDT-EC-USBX.aml, SSDT-HPET.aml and SSDT-PLUG.aml were generated using SSDTTime and my system's DSDT.aml.

I don't see where the SSDT-EC-USBX.aml comes from in SSDTTime. I only get SSDT-EC.aml when running the various options in SSDTTime.