Beiträge von Mieze

    Da das Angebot von Macintosh-tauglichen Sockel 1200 Boards mittlerweile arg geschrumpft ist und für die wenigen noch lieferbaren Modelle inzwischen Mondpreise verlangt werden, dürfte ein neues Sockel 1700 Board für DDR4-RAM + CPU wahrscheinlich billiger kommen, zumal Alder Lake CPUs inzwischen spottbillig geworden sind. Die günstigsten brauchbaren Boards mit B760 gibts schon für ca. 100€ und Z790 ab 150€.

    DarkBlueNight Ich vermute mal, dass dies ein Konfigurationsproblem mit dem Switch ist, da bei einem Managed Switch üblicherweise Jumbo Frames neben den globalen Einstellungen, auch in den Einstellungen pro Port aktiviert werden müssen.


    Üblicherweise kümmern sich Kommunikationsendpunkte per Path MTU Discovery automatisch darum, die richtige MTU für eine Verbindung auszuhandeln. Das Deaktivieren von bestimmten ICMP-Messages in den Sicherheitseinstellungen kann Path MTU Discovery jedoch sabotieren, da dann die entsprechende ICMP-Message nicht ankommt.


    Grundsätzlich sind Jumbo Frames nur für Muti-Gigabit-Ethernet standardisiert, bei Gigabit-Ethernet sind sie ein optionales Feature, welches mangels Standardisierung aber zu Problemen führen kann. WLAN unterstützt überhaupt keine Jumbo Frames. Einen echten Performance-Gewinn erzielt man aus diesem Grund in der Regel nur, wenn alle Verbindungen zwischen den beiden Kommunikationsendpunkten >1Gbit/s haben. Von daher dürftest Du wahrscheinlich bei deinem Setup eh keinen Vorteil draus ziehen. Solange dein NAS/Server noch mit 1Gbit läuft, gibt es daher keine Notwendigkeit Jumbo Frames nutzen.

    MacGrummel Ein neues Betriebssystem auf einer NVMe installieren und dann die Daten aus Time Machine zurückzuspielen habe ich in der Vergangenheit regelmäßig immer mal wieder machen müssen, jedesmal wenn Apple mir mit einem verkackten MacOS-Update das System lahm gelegt hat, weil das der einzige Weg ist, zur alten Version zurückzukommen. Wenn dadurch die ewigen Bootzeiten beseitigt worden wären, dann wäre mir das definitiv aufgefallen. Ist es aber nicht, also muss sich irgend etwas geändert haben. Das MSI MPG Z490 Gaming Plus habe ich im vergangenen November so aufgesetzt, als ich das Board bekommen habe, aber das Booten hat von Anfang an ewig gedauert. Außerdem habe ich neue Versionen immer erst mal in einem neuen Volume zum Testen installiert. Da gab es auch keinen Unterschied bei den Bootzeiten zum Hauptsystem.

    Ich habe jetzt die 980 Pro aus meinem Server herausgeholt und in mein Hauptsystem (Gigabyte Z790 D + 12700KF) eingebaut, Sonoma 14.6.1 installiert und mit dem Migrationsassistenten meine Daten wiederhergestellt. Die 980 Pro hängt jetzt direkt an der CPU und der Rechner bootet flott mit ApfsTrimTimeout = -1.


    Hier noch mal eine Zusammenfassung der getesteten Konfigurationen (jeweils mit ApfsTrimTimeout = -1):

    1. Gigabyte Z490 Gaming X + Core i9-11900KF + 970 Evo im M.2-Slot an der CPU (macOS 14.5 / 14.6 / 14.6.1 / 14.7) -> OK!
    2. Gigabyte Z790 D + Core i7-12700KF + 980 Pro im M.2-Slot an der CPU (macOS 14.6.1) -> OK!
    3. MSI MPG Z490 Gaming Plus + Core i7-10700 + 970 Evo im M.2-Slot am PCH (macOS 14.5) -> nicht OK!

    Offensichtlich tritt das Problem nur auf, wenn die NVMe am PCH hängt. MacGrummel hatte ja schon berichtet, dass es mit externen Samsung SSDs keine Probleme gibt, während die internen gemischte Resultate zeigten.

    Bei der Frage, was könnte diese Konfigurationen unterscheiden, so dass dieses Problem auftritt oder nicht fällt meine Vermutung spontan auf Power Management, genauer genommen auf ASPM. Sollte die TRIM-Problematik bei Samsung NVMes also evtl. mit ASPM zusammenhängen, da die Konfigurationen sich in diesem Fall definitiv unterscheiden? Was denkt ihr?

    Ich habe hier in meinem Hauptsystem auch noch eine Karte, die für den Smalltree-Treiber gepatched war und zuverlässig mit IntelLucy läuft. Bevor ich IntelLucy geschrieben habe, hatte ich ebenfalls den Smalltree-Treiber genutzt.


    IntelLucy wird wie jede andere Kext über OpenCore eingebunden. Die nötigen Einträge für die config.plist findest Du ebenfalls in der Anleitung auf IM.

    Ich kann auch noch einen weiteren Bug-Report beitragen. Das ist jetzt war kein spezielles Problem von Sequoia, da Safari 18.0 auch für Sonoma angeboten wird, aber das Update auf 18.0 (unter Sonoma 14.7) war definitiv ein Fehler. Wenn man mit 18.0 einen Download auf einer SAMBA-Freigabe speichert, dann wird er nicht mehr entpackt, sondern es bleibt dort nur eine .download-Datei zurück, die man im Finder noch nicht mal umbenennen kann. Möchte man sie dennoch entpacken, so muss man im Terminal durch Umbenennen das Suffix .download entfernen. Speichert man den Download hingegen auf einem APFS-Volume lokal, so tritt das Problem nicht auf. Ursache dürfte wohl die Nutzung spezieller Extended Attributs sein, die von SAMBA nicht unterstützt werden. Ok es gibt schlimmere Bugs, aber sowas sollte eigentlich nicht passieren, wenn man SMB als Standardprotokoll für Filesharing empfiehlt.


    Das Schlimmste daran ist, dann man nicht einfach auf Version 17.6 downgraden kann, weil Safari keine normale App ist, sondern ins System integriert ist und durch SIP geschützt wird. ||


    EDIT: Ein Downgrade von Safari alleine ist nicht mehr möglich. Die Einzige Möglichkeit zum Downgrade besteht darin, das ganze System von einem Time Machine Backup wiederherzustellen.

    cobanramo Business as usual! Neue Versionen von MacOS haben seit dem Ende der Ära von Steve Jobs leider nur noch Beta-Qualität und brauchen noch ca. 6 Monate, bis sie reif für den Produktiveinsatz sind. Ich habe Sonoma erst im März installiert und werde wohl auch bis zum März 2025 warten, bis ich auf Sequoia update.


    Aber es ist gut schon mal zu wissen, welche Bugs Sequoia gegenwärtig noch hat. Von daher in jedem Fall vielen Dank für's Testen!

    Ich bin der Sache mal etwas genauer auf den Grund gegangen und habe die apfs.kext von Ventura (13.6.6) und Sonoma (14.7) verglichen. Beide haben die Versionsnummer 11.4 und sind fast gleich groß (5309 Bytes gegen 5310 Bytes), so dass sich am Treiber mit hoher Wahrscheinlichkeit nichts geändert hat. Das würde drauf hindeuten, dass andere Ursachen für das Problem verantwortlich sind.


    Also, was habe ich sonst noch geändert?


    Bis vor einem Monat wurde die 970 EVO mit einem MSI MPG Z490 Gaming Plus (mit Core i7-10700) genutzt und steckte in einem M.2-Slot, der am PCH angebunden ist. Dort gab es das Problem mit den langen Bootzeiten.


    Im August habe ich sie dann in ein anderes System eingebaut, welches mit einem Gigabyte Z490 Gaming X und Core i9-11900KF ausgestattet ist. Dieses Board besitzt einen als "reserved" gekennzeichneten M.2-Slot, der direkt an der CPU hängt, und nur mit Prozessoren der 11. Generation genutzt werden kann. In diesem Slot habe ich die 970 EVO installiert und seitdem waren die langen Bootzeiten Geschichte.


    Sollte also evtl. nicht der Treiber, sondern die Anbindung an das System für die Trim-Probleme verantwortlich sein, welche zu langen Bootzeiten führen? Wie sieht es mit SSDs von Samsung aus, die in externen Thunderbolt-Gehäusen installiert sind? Dauert das Booten von diesen Laufwerken ebenfalls so lange?


    Früher vor einigen Jahren steckte die 970 EVO in dem Gigabyte Z490 Gaming X mit Core i7-10700 und war über den PCH angebunden. Damals hatte ich ebenfalls lange Bootzeiten, was auch der Grund war, sie durch eine andere SSD zu ersetzen. :think:

    Ist Euch auch schon aufgefallen, dass seit MacOS 14.5 das Problem mit den langen Boot-Zeiten bei Samsung SSDs verschwunden ist? Mein Zweitsystem mit einer 970 EVO, welches früher über eine Minute zum Booten brauchte, bootet jetzt richtig flott, obwohl ich NVMeFix.kext entfernt und ApfsTrimTimeout = -1 gesetzt habe.


    Könnt Ihr diese Beobachtung auch bei anderen SSDs von Samsung bestätigen?


    Edit: Bitte bei Antworten immer Mainboard, CPU und wie die SSD an das System angebunden ist (CPU, PCH oder TB) nennen. Danke!

    apfelnico DIe Subsystem Dev ID sollte eigentlich keinen Einfluss auf die Funktion des Treibers haben, jedenfalls nicht mit dem X550. Welchen Switch verwendest Du und mit welcher Geschwindigkeit arbeitet der Port?


    Hattest Du mal versucht das medium manuell auszuwählen. Ich habe im Linux source code lesen, dass N-Base-T bei manchen Switchen zu Problemen führen kann.


    des Weiteren hatte ich in Deinen BIOS-Einstellungen gesehen, dass ASPM deaktiviert ist. Evtl. solltest Du mal versuchen in der IntelLucys Info.plist "enableASPM" auf false zu setzen, da der Treiber versucht ASPM zu aktivieren, falls der Chip das unterstützt, was beim X550 der Fall ist.


    Kernel Logs zu sammeln ist relativ schwierig, da hierzu SIP deaktiviert und der Treiber in /L/E installiert werden muss.