[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[CaseySJ]

View attachment 532134
Please note, my machine won't boot if I enable the IntelBluetoothinjector. It's been this way from the outset. Thanks.

Have you tried replacing BlueToolFixup.kext in EFI/OC/Kexts folder with the one in this post:

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

Will there be a Monterey install mini-guide? :D I may need to create a formal one soon. But in the meantime, please use this one (only 3 steps): https://www.tonymacx86.com/threads/gigabyte-z490-vision-d-thunderbolt-3-i5-10400-amd-rx-580.298642/post-2282235 Note that on Z390 Designare the Intel...

www.tonymacx86.com

 

[CaseySJ]

Hi @CaseySJ... hope you are fine....

I'm definitively with problems on my boot time on Monterey, which is taking way too long... here's my output:

kernel: (apfs) spaceman_scan_free_blocks:3153: disk3 scan took 204.819595 s, trims took 204.469358 s
kernel: (apfs) spaceman_scan_free_blocks:3153: disk6 scan took 4.581236 s, trims took 4.018021 s
kernel: (apfs) spaceman_scan_free_blocks:3153: disk4 scan took 42.122163 s, trims took 41.525545 s

Hello @ummario,

Are you using Samsung NVMe SSD? If so, which model?

In Terminal can you please type diskutil list and post the output? Disk3 is taking way too much time!

 

[NCMacGuy]

Can you run this command in Terminal:

log show --last boot | grep "trims took"

... and press CTRL-C after about 15 seconds. I'd like to see if there are any trim operations that consume either 68 or 34 seconds to account for the delays you experienced.

@CaseySJ



Yes, there was a long trim for disk3, the Monterey 970 EVO boot drive, and disk4 the external 970 EVO TB3 boot drive.

So Monterey trim is burning up boot time. This is even with the -1 changed to 999 in config.plist. Same drives in Big Sur apparently take much less trim time.

 

[CaseySJ]

@CaseySJ

View attachment 532136

Yes, there was a long trim for disk3, the Monterey 970 EVO boot drive, and disk4 the external 970 EVO TB3 boot drive.

So Monterey trim is burning up boot time. This is even with the -1 changed to 999 in config.plist. Same drives in Big Sur apparently take much less trim time.

It now looks more and more likely that trim on Samsung SSDs might be the cause, and also seems we cannot disable trim, at least not with current implementation of SetApfsTrimTimeout. The wizards at acidanthera may well find a solution in short order.

 

[ummario]

Hello @ummario,

Are you using Samsung NVMe SSD? If so, which model?

In Terminal can you please type diskutil list and post the output? Disk3 is taking way too much time!

1) Yes I have Samsung NVME: 970 Evo

2) here's the result of diskutil list:

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI ⁨EFI⁩ 209.7 MB disk0s1
2: Apple_APFS ⁨Container disk4⁩ 1000.0 GB disk0s2

/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: Windows Recovery ⁨⁩ 523.2 MB disk1s1
2: EFI ⁨NO NAME⁩ 104.9 MB disk1s2
3: Microsoft Reserved ⁨⁩ 16.8 MB disk1s3
4: Microsoft Basic Data ⁨⁩ 498.9 GB disk1s4
5: Windows Recovery ⁨⁩ 589.3 MB disk1s5

/dev/disk2 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk2
1: EFI ⁨EFI-SAM-26Z⁩ 209.7 MB disk2s1
2: Apple_APFS ⁨Container disk3⁩ 1000.0 GB disk2s2

/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk3
Physical Store disk2s2
1: APFS Volume ⁨Big Sur - Data⁩ 327.3 GB disk3s1
2: APFS Volume ⁨Preboot⁩ 539.5 MB disk3s2
3: APFS Volume ⁨Recovery⁩ 1.1 GB disk3s3
4: APFS Volume ⁨VM⁩ 1.1 MB disk3s4
5: APFS Volume ⁨Big Sur⁩ 15.7 GB disk3s5
6: APFS Snapshot ⁨com.apple.os.update-...⁩ 15.7 GB disk3s5s1

/dev/disk4 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk4
Physical Store disk0s2
1: APFS Volume ⁨carbon⁩ 350.5 GB disk4s1


/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +11.1 TB disk5
1: EFI ⁨EFI⁩ 209.7 MB disk5s1
2: Apple_APFS ⁨Container disk6⁩ 11.1 TB disk5s2


/dev/disk6 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +11.1 TB disk6
Physical Store disk5s2
1: APFS Volume ⁨Backups of Mario’s iMac⁩ 844.0 GB disk6s1


note: on disk 3 says Big Sur, but it's now installed Monterey, I still didn't changed the name

 

[Hackintoshron]

@jiffyslot @Hackintoshron

Please see post directly above. We should try the pre-release BlueToolFixup kext in that post.

Note however that it may or may not make a difference with BCM94360 module, but worth trying anyway.

New BluetoolFixup did the trick guys!! Bluetooth is back and rolling! Thanks!

 

[CaseySJ]

1) Yes I have Samsung NVME: 970 Evo

2) here's the result of diskutil list:

...

/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk3
Physical Store disk2s2
1: APFS Volume ⁨Big Sur - Data⁩ 327.3 GB disk3s1
2: APFS Volume ⁨Preboot⁩ 539.5 MB disk3s2
3: APFS Volume ⁨Recovery⁩ 1.1 GB disk3s3
4: APFS Volume ⁨VM⁩ 1.1 MB disk3s4
5: APFS Volume ⁨Big Sur⁩ 15.7 GB disk3s5
6: APFS Snapshot ⁨com.apple.os.update-...⁩ 15.7 GB disk3s5s1

...


note: on disk 3 says Big Sur, but it's now installed Monterey, I still didn't changed the name

So disk3 is the Samsung 970 Evo? If so, that is the one suffering from 204 seconds of trim time! Ouch!

 

[ummario]

So disk3 is the Samsung 970 Evo? If so, that is the one suffering from 204 seconds of trim time! Ouch!

Yep!.... that's what I wait every time I boot... is not a big deal, since is turned on most of the times... anyway Is boring... do you think a fix might be possible?

 

[yosoyoco]

** Experiencing Slow Boot Times in Monterey? **​

Please try this and report your results:

• In Terminal, type:

log show --last boot | grep "trims took"

• Give it a few seconds to run then press CTRL-C to stop.
• Post the output.

Here's the result from my Z490 Vision D with release version of Monterey:

kernel: (apfs) spaceman_scan_free_blocks:3153: disk3 scan took 1.913441 s, trims took 1.786507 s
kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 2.299866 s, trims took 2.262432 s

Note that both operations took less than 3 seconds.

kernel: (apfs) spaceman_scan_free_blocks:3153: disk5 scan took 87.787166 s, trims took 87.625965 s
Samsung 970 EVO Plus

 

[CaseySJ]

Yep!.... that's what I wait every time I boot... is not a big deal, since is turned on most of the times... anyway Is boring... do you think a fix might be possible?

kernel: (apfs) spaceman_scan_free_blocks:3153: disk5 scan took 87.787166 s, trims took 87.625965 s
Samsung 970 EVO Plus

The evidence is mounting that Samsung 970 EVO and EVO Plus are having this problem. I am hopeful that acidanthera can find a way to disable trim on these models. The current implementation of SetApfsTrimTimeout does not seem to work.