Long 15 Second "Pause" During Boot

[Edhawk]

I probably renamed the SSDT-EC.aml, as it also contains the USB sleep/power settings.

If you open both your SSDT-EC.aml and my SSDT-EC-USBX.aml (use MaciASL - https://github.com/acidanthera/MaciASL) you will see the difference between the two tables.

 

[ski4evr]

@Edhawk, looking at my SSDT-EC generated by SSDTTime and your SSDT-EC-USBX, I can see you added the highlighted section for USB. Why is that added? And why add it to the EC?

Also, looking at the generic SSDT-EC from the OpenCore Install Guide... there's a HUGE difference. Only one entry for the one generated by SSDTTime and 31 entries for the generic one. Wow.


My SSDT-EC

Your SSDT-EC-USBX

 

[Edhawk]

I added the USB power settings to the SSDT-EC.aml to make sure they were correct for my Haswell systems and so I only required a single SSDT rather than two. I think at the time I was using an SSDT-UIAC.aml for my USB configuration and it didn't contain the USB power section. The USBPorts.kext I later moved to (same configuration but kext instead of SSDT) contains the USB power settings, so I probably should use a straight SSDT-EC.aml.

I found that editing and creating combination SSDT's is fairly straightforward when you don't want to change or add too much to the original.

The SSDT-EC.aml and SSDT-PLUG.aml from Dortania are similar in the respect they try to cover a lot of different settings/options for a multitude of systems. That is why they are slower to load and why I don't recommend using them other than as a first boot/installation. Once you have macOS up and running creating custom SSDT's that work specifically with your system is a much better way to go.

 

[ski4evr]

Updated my EFI folder with new SSDT's generated by SSDTTime. My SSDT-EC only has one entry vice the 30+ of the generic one. Similar scenario for the SSDT-PLUG. I added the SSDT-HPET and required config.plist patches.

No change in the Long Boot Pause. Still 15 seconds where it sits with a static verbose screen. However, the overall boot process is about 3-4 seconds faster getting to the desktop.

Puzzling.

 

[Edhawk]

Do you have Trim enabled for a SSD or NVME drive?

If yes, try disabling Trim, either in the config.plist (ThirdPartyDrives - needs to be False/No) or via Terminal if you used the 'sudo TrimForce Enable' command. Then see if turning Trim off changes how the system boots.

Issues with Samsung NVME drives seem to be common with new versions of macOS. That doesn't mean that other makes of SSD and NVME drives won't have similar if less obvious/dramatic issues.

 

[ski4evr]

Do you have Trim enabled for a SSD or NVME drive?

No Trim. Config.plist has it off, too (ThirdPartyDrives = NO).

 

[Edhawk]

Yeah, that looks fine. I'm out of ideas as to what could be causing the delay.

 

[ski4evr]

I turned Trim on. I don't think I ever had it enabled.

I'm still getting the 15 sec delay starting about 15 seconds into the boot. I disabled these kexts to see if they were potentially causing the delay:

• AirportBrcmFixup
• BrcmBluetoothInjector
• BrcmFirmwareData
• BrcmPatchRAM3

Nope. 15 sec delay still exists. I'm thinking I should just ignore it and move on.

I am going to do a clean install of Big Sur 11.6.2. I'm on 11.2.3. We'll see if that changes anything.

 

[Edhawk]

Make sure your USB configuration is correct before you run the update as the Kernel > Quirk > XhciPortLimit entry doesn’t work in versions of Big Sur 11.3 and newer.