Beiträge von spacepilot3000

    LÖSUNG für das TRIM Problem mit NVME:




    Klappt bei mir (auch ohne NVRAM reset):


    Those who are suffering to slow boot issues in Monterey due to NVMe please read this post carefully:

    For fixing that slow boot issue you can follow the following steps:

    Update OC to 0.7.9 (Oc 0.7.8 or lowers does not work with the fix)

    In config.plist go to kernel > Quirks > SetApfsTrimTimeout

    set the value from -1 to 0

    Save

    Reboot and reset Nvram.

    It should fix your issue.

    N.B:

    This fix works only with OC 0.7.9 (Till today's date 12-02-2022)

    Tested with latest Monterey stable 12.2.1 (Till today's date 12-02-2022)

    LÖSUNG, klappt bei mir (auch ohne NVRAM reset):


    Those who are suffering to slow boot issues in Monterey due to NVMe please read this post carefully:

    For fixing that slow boot issue you can follow the following steps:

    Update OC to 0.7.9 (Oc 0.7.8 or lowers does not work with the fix)

    In config.plist go to kernel > Quirks > SetApfsTrimTimeout

    set the value from -1 to 0

    Save

    Reboot and reset Nvram.

    It should fix your issue.

    N.B:

    This fix works only with OC 0.7.9 (Till today's date 12-02-2022)

    Tested with latest Monterey stable 12.2.1 (Till today's date 12-02-2022)

    spacepilot3000


    Danke.Bei der Plattform nutzt Du iMacPro1,1, ich hatte MacPro7,1. Gibts da Unterschiede. Kann ich meine Seriennummer/UUID MLB ROM weiter verwenden?

    Ich hatte Probleme mit dem MacPro7,1 als Basis. Habe mir eine eigene UUID, Serial und co. Im hackintool generieren lassen. Nach Reboot war die cloud damit sofort einverstanden. Ich glaube das muss passen, also behalten kannst Du die alten settings daher nicht.

    Bekomme grad das Problem, dass seit heute auf allen Geräten( Pad, Phone, Hacki) ständig meine AppleID überprüft werden soll. Meist kommt dann auf den Endgeräten Unbekannter Fehler oder this action cannot be completed at this time, und ich erhalte erneut ein Login Fenster. Das lief jetzt Monate super - hab auch keine Configs geändert. Hat so etwas auch akut jemand? Bin unsicher ob das mit dem Hacki zusammen hängt...

    Entschuldigt, wenn ich den Thread hier nochmal kapere. Ich habe tatsächlich den BESTEN Hinweis bekommen, wenn BT mal nicht mehr geht den Rechner wirklich so 10sek komplett stromlos zu machen. Mit meinem neuen Board passiert mir das mit der verwirrten FW hin und wieder bei Reboots oder auch beim Wechsele Windows/Monterey.


    Meine Frage - Was ist der Hintergrund? Kann ich was präventiv unternehmen, damit BT nicht zwischendrin aus dem Grund spinnert? Wenn hier jemand den Deepdive angehen mag, ich wäre bereit :-D


    Danke!

    Ich hatte hier: Luxusproblem: Bootzeit. Pause von 40Sek bei "bootroot" in Monterey 12.1 einen zweiten Thread eröffnet, da ich den Zusammenhang erst nicht hinbekommen habe.


    Nutze eine Crucial NVMe 1TB CT1000P2SSD8 und hatte/habe das selbe Problem... Nach guten Hinweisen zum Thema habe ich heute meiner Crucial die neueste Firmware (Allerdings auch bereits von 02/2021) verpasst. Danach hat sich markant etwas getan:


    VOR dem Update hat der Hacki verlässlich etwa 150 Sekunden getrimmt:

    2021-12-23 18:08:05.681862+0100 0x3a3 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 0.257032 s, trims took 150.929044 s



    NACH dem Update trimmt er nun stets bei 51s

    2021-12-27 10:32:17.578211+0100 0x3ee Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 51.939741 s, trims took 51.728071 s


    Spannend ist auch die Änderung bei Scan/Trim - Dazu habe ich noch keine echte Erklärung.


    Obwohl es ja tatsächlich egal sein sollte, aber mein Trim Timeout ist aktuell auf -1, NVMefix Kext aktiv

    Eine kleine Erkenntnis:


    Nachdem ich heute meiner Crucial die neueste Firmware (Allerdings auch bereits von 02/2021) verpasst habe, hat sich markant etwas getan:


    VOR dem Update hat der Hacki verlässlich etwa 150 Sekunden getrimmt:


    2021-12-23 18:08:05.681862+0100 0x3a3 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 0.257032 s, trims took 150.929044 s

    NACH dem Update trimmt er nun stets bei 51s


    2021-12-27 10:32:17.578211+0100 0x3ee Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 51.939741 s, trims took 51.728071 s


    @ Moderator - Ich teile das mal im Ursprungsthread, dann kann dieser hier wegen "doppelt" zu. Danke!

    Wenn ich eines nicht bin: Zu faul zum Suchen. Schade, dass dies immer zuerst angenommen wird.


    Leider kann ich die Zeilen "dahinter" nicht sehen, da es zu fix wegscrollt. Die Suche brachte mir nicht wirklich etwas.


    Zunächst denke ich, trim könnte mein Problem sein:


    Disk2 ist der APFS Container mit Monterey drin auf einer Crucial CT1000P2SSD8 Disk:


    12-23 18:05:34.446281+0100 0x3cb Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 139132928

    2021-12-23 18:05:34.446284+0100 0x3cb Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 151748608

    2021-12-23 18:05:34.446287+0100 0x3cb Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 93388800

    2021-12-23 18:05:34.446290+0100 0x3cb Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 151453696

    2021-12-23 18:05:34.575664+0100 0x3cb Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3171: disk2 scan took 0.129344 s (no trims)

    2021-12-23 18:08:05.681862+0100 0x3a3 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 0.257032 s, trims took 150.929044 s

    2021-12-23 18:08:05.681869+0100 0x3a3 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3155: disk2 164083574 blocks free in 236523 extents

    2021-12-23 18:08:05.681873+0100 0x3a3 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3163: disk2 164083574 blocks trimmed in 236523 extents (638 us/trim, 1567 trims/s)

    2021-12-23 18:08:05.681878+0100 0x3a3 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3166: disk2 trim distribution 1:74339 2+:48688 4+:47484 16+:24471 64+:15963 256+:25578


    Richtig?


    Ich habe jetzt versucht trimforce disable - Kein Unterschied - bin zurücke auf enable

    Im OC habe ich den Parameter nun auf SetApfsTrimTimeout = 999, SetApfsTrimTimeout = -1 und SetApfsTrimTimeout = 1 gesetzt. Ändert nichts.


    Somit bin ich jetzt "im Club"- da der Ur-Thread auch mit Schulterzucken endet... richtig?

    Ein vorweihnachtliches Moin in die Runde!


    Nachdem mein EFI nun tatsächlich sehr gut funktioniert und alle LAN/WLAN/BT Probleme usw. ausgemerzt sind, bastle ich noch immer an einem kleinen Problem herum. Beim Booten verliere ich immer ca. 40 Sekunden an der folgenden Stelle:


    ?thumbnail=1


    com.apple.xpc launchd (....) Doing boot task: bootroot


    Was tut der hack da?


    Ich bin offen für Ideen! Danke Euch!


    Grüße,


    David

    Moin! Mit Beta4 ist leider trotz aktuellem BTFixup mein BT Adapter komplett verschwunden.


    Ich benutze die IntelBluetoothFirmware.kext, BluetoolFixup.kext


    Sehe, dass der BT Prozess ale paar Sekunden crasht. Was hab ich verpasst? :-D


    2. Update: KOPF->TISCH

    Ich erinnerte mich grad an einen gaaaanz alten Tipp aus dem Forum hier. Habe mal den Rechner aus gemacht, Strom ab, 10 Sekunden. Boot, BT wieder da. AUA....