Bluetooth instability in macOS Monterey about hackintosh

[hanselsin]

I suppose the slow boot time to several minutes might not be due to Bluetooth but rather the Samsung 970 EVO Plus SSD incompatibility with Monterey SSD TRIM handling. Google it on the net and you can find quite a lot of discussions these days. Right now I am switching the OpenCore SetApfsTrimTimeout=4299999999 (the actual value is the 32-bit unsigned MAX, just check it out yourself) to length macOS kernel to wait for Samsung SSD TRIM command returns.

[shiruken]

Hmm interesting... Does increasing the timeout to max allow the trim operation to complete on Samsung SSDs and result in faster subsequent boots? Or is this just a fix to allow the trim operation to run properly without resolving the boot time issues?

Also, 4294967295 is the highest value for a 32-bit unsigned int. Setting it higher may not be allowed or could cause overflow problems.

[hanselsin]

Check this out from OpenCore developers:

dortania/bugtracker#192

Since the TRIM protocol between macOS Monterey and Samsung is now broken, setting the value to 32-bit MAX simply forces macOS kernel to wait -nearly- indefinitely long for Samsung SSD to complete each TRIM command, since we scared it will kill the SSD due to too many TRIM commands issued concurrently. I also wonder if the 4294967295 is really needed or not (say maybe just 10000000 even in ms is more than enough), so far no one has a concrete answer yet.

[shiruken]

Seems like setting it to any very high number would be suitable. 4294967295 is just convenient because it is the max allowable number (OpenCore appears to use 32-bit unsigned int for plist int fields).

[shiruken]

Removed boot slowdowns from this issue and created #15