Slow Boot time with Samsung 960 Evo NVME?

[telepati]

Hi, after clean install High Sierra to Samsung 960 EVO NVME, my boot time is very slow. Boot time now is 50s sometimes 60s. My earlier 840 SSD much faster than this NVME.

I checked the verbose, where the boot most hang out, its coming here and stoping here almost 15 seconds, then start the boot. Here is the verbose screen;



I attached all "Problem Reporting" files.

 

[RehabMan]

Hi, after clean install High Sierra to Samsung 960 EVO NVME, my boot time is very slow. Boot time now is 50s sometimes 60s. My earlier 840 SSD much faster than this NVME.

I checked the verbose, where the boot most hang out, its coming here and stoping here almost 15 seconds, then start the boot. Here is the verbose screen;

View attachment 279658

I attached all "Problem Reporting" files.

ACPI/patched is out of sync with native.
Note different SystemMemory addresses:

SPEEDY-NUC:origin rehabman$ diff ../origin/ ../patched/ |grep SystemMemory
<     OperationRegion (GNVS, SystemMemory, 0x8A860000, 0x06B3)
>     OperationRegion (GNVS, SystemMemory, 0x8A899000, 0x06B3)
<                 OperationRegion (CPSB, SystemMemory, 0x89FDFF98, 0x10)
>                 OperationRegion (CPSB, SystemMemory, 0x8A018F98, 0x10)
<                 OperationRegion (XMIO, SystemMemory, Local0, 0x9000)

 

[telepati]

ACPI/patched is out of sync with native.
Note different SystemMemory addresses:

SPEEDY-NUC:origin rehabman$ diff ../origin/ ../patched/ |grep SystemMemory
<     OperationRegion (GNVS, SystemMemory, 0x8A860000, 0x06B3)
>     OperationRegion (GNVS, SystemMemory, 0x8A899000, 0x06B3)
<                 OperationRegion (CPSB, SystemMemory, 0x89FDFF98, 0x10)
>                 OperationRegion (CPSB, SystemMemory, 0x8A018F98, 0x10)
<                 OperationRegion (XMIO, SystemMemory, Local0, 0x9000)

are you saying my ACPI/Patched are out of sync with native?

is this some kind of "Floating regions" problem right? And I think you mentioned about this on DSDT/SSDTs guide?

 

[RehabMan]

are you saying my ACPI/Patched are out of sync with native?

is this some kind of "Floating regions" problem right? And I think you mentioned about this on DSDT/SSDTs guide?

Yes.
You need to re-extract/re-patch ACPI.
Then avoid making any changes to BIOS options, BIOS version, or installed hardware that would change those addresses... otherwise, you'll need to do it again.

The alternative is to avoid putting patched files in ACPI/patched by patching with Clover config.plist options and additional SSDTs, which is known as "hotpatch."

 

[telepati]

Yes.
You need to re-extract/re-patch ACPI.
Then avoid making any changes to BIOS options, BIOS version, or installed hardware that would change those addresses... otherwise, you'll need to do it again.

The alternative is to avoid putting patched files in ACPI/patched by patching with Clover config.plist options and additional SSDTs, which is known as "hotpatch."

Thanks the details. I think I know when this happened. Before the install High Sierra I disconnected my other drives after finished the clean install on NVME put them all back and change couple of settings from BIOS. Probably all these changes effected this.

Good to know. I will be much careful from now.

Thank you again.

 

[RehabMan]

are you saying my ACPI/Patched are out of sync with native?

is this some kind of "Floating regions" problem right? And I think you mentioned about this on DSDT/SSDTs guide?

Keep in mind all of the patches you applied to your ACPI/patched/DSDT.aml are either not needed, wrong, or easily accomplished with Clover hotpatch or add-on SSDTs.

 

[telepati]

Keep in mind all of the patches you applied to your ACPI/patched/DSDT.aml are either not needed, wrong, or easily accomplished with Clover hotpatch or add-on SSDTs.

One more thing; ssdtPRGen.sh is still need it? I read your post I dont know exactly where but you are said after Haswell no need the ssdtPRGen.sh. is that true?

 

[RehabMan]

One more thing; ssdtPRGen.sh is still need it? I read your post I dont know exactly where but you are said after Haswell no need the ssdtPRGen.sh. is that true?

SSDT.aml from ssdtPRgen.sh is not needed when using XCPM (usually Haswell or later, although it is possible to use XCPM for Ivy Bridge).

All that is necessary is to inject "plugin-type"=1 on CPU0.

There are two ways:
- use SSDT-PluginType1.aml (toleda calls the same thing SSDT-XCPM.aml)
- if using my fork of Clover, use config.plist/ACPI/SSDT/Generate/PluginType=true

It is covered in the laptop PM guide (which really is not specific to laptops):
https://www.tonymacx86.com/threads/guide-native-power-management-for-laptops.175801/

 

[svencux]

i had a slow booting system as well.
Deleting the patch to enable trim support was doing the trick. Now boot times
are as they were with Sierra.

see this post as well.
https://www.tonymacx86.com/threads/clover-does-not-install-on-efi-partition-of-hs.231530/page-2

 

[erice]

Hi everyone and to the attention of RehabMan.

With High Sierra, if I enable Trim support, I have:

1) slow start issues (40'')
after row
- (apfs) apfs_mount_update:17785: er: mount check: ro->rw update: no encryption rolling in progress, bailing.
before rows:
- (apfs) er_state_obj_get_for_recovery: 3682: No ER object - rolling is not happening, nothing to recover.
- (apfs) handle_mount: 254: vol-uuid: 42581E64-0633-4338-A556-AFBEFF7E020F block size: 4096 block count: 58556556 (unencrypted; flags: 0x1; features: 1.0.2)
- (apfs) apfs_vfsop_mount: 1331: mounted volume: VM .

2) ACPI errors [SANV] and [_DSM] and "ACPI: Can not translate ACPI object 14" in System Bootlog.

3) Frequent "Wake reason: PEGP" if I ask Stop.

I really understand that it is very boring for you, but would you be so kind to help me solve something?

Sorry for my bad english and very thanks in advance.
Giuseppe