Dauerabstürze vom X299 unter Sequoia (&Sonoma) durch TSC-Sync ??

Rechner: Asus Prime X299 Deluxe II, CPU i9/9900X 10-Kerner, Grafik Vega FE LC & Vega 2 = Radeon Pro VII über TB, Intel-Lan X540 2x10G, Broadcom WLAN & Bt BCM94360NG, System Sequoia m. Broadcom-Patch, Booter OC & Clover

Seit einiger Zeit "friert" mein X299er mit macOS Sequoia ständig ein, er bleibt sozusagen mitten in seinen Aufgaben stehen. Er läuft und arbeitet für einige Zeit ganz normal, aber dann ist plötzlich Schluss.

Am Anfang war das vielleicht einmal die Woche, unterdessen ist es wiederholbar bei Lastveränderungen, Auch ohne Benutzen der Tastatur, wenn eine Aufgabe zu Ende ist oder wenn ich zB. nach längerer Pause Photoshop starte. Wenn er nur Hintergrund-Arbeiten verrichtet von Nachrichten Empfangen bis EyeTV Wiedergeben läuft er Stunden durch, dann reicht schon eine kleine Änderung.

Ein Cache-Problem? Ein Buffer Overflow?

Als seltener Fehler ist das vielleicht nicht wirklich schlimm, aber wenn es vorhersehbar dann eintritt, wenn der Rechner seine eigentliche Aufgabe erfüllen soll, .... Murks!

Über die vergangenen Wochen hab ich deshalb viel experimentiert:

• Hängt irgendwo was dran am Rechner, dass für Abstürze sorgen könnte? Alles abgezogen, keine Änderung, Abstürze gab es auch ohne!
• Liegt's am Broadcom-Patch? Nein, Abstürze gab es auch ohne!
• Liegt's am Intel-10G-Lan? Nein, Abstürze gab es auch ohne!
• Liegt es an der Vega II im Thunderbolt-Kasten? Nein, Abstürze gab es auch ohne!
• Liegt es an der Vega FE? Nein, Abstürze gab es auch mit stattdessen eingebauter Vega II.
• Liegt es am Booter? Nein, da machen Clover und OC keinen Unterschied!
• Liegt es an Sequoia? Ja und Nein: Mit Sonoma gibt es die Abstürze auch, mit Ventura dagegen nicht. Also Sonoma UND Sequoia!
• Letztlich bin ich durch meinen X99er auf die Lösung gekommen, woran es denn scheinbar hängt:

Auch der ist bei Belastungsänderungen unter Sonoma und Sequoia eingefroren.

Also hab ich nach Gemeinsamkeiten zwischen den beiden Dickschiffen gesucht, die meine anderen Rechner nicht haben.

Letztlich blieben nur die TSC-Sync-Kexte als Fehlerquelle übrig.

Und da hilft dann ja auch mal der Blick in die eigenen Archive weiter: Eigentlich braucht der X99 diese Kexte nicht, hatte er früher bei mir auch nicht.

Also den CpuTscSync.Kext dort deaktiviert - und seitdem kein einziger Absturz dort.

Dann weiter in meinen Archiven gesucht: es gab doch da mal einen anderen Kext..

In meinem ersten Thread zum X299er steckte noch die Alternative: der TSCAdjustReset.kext. Da musste in der Info-PListe die Zahl der arbeitenden Kerne eingetragen werden (-1!) , sonst ging der auch. Und bei irgendeinem Update sogar besser..

Also den damals laufenden Kext mit den Eintragungen genommen - geht aber nicht. War für eine viel ältere Lilu-Version und damals noch für den FakeSMC.Kext geschrieben. Auch nagelneu mit der "19" an der richtigen Stelle wollte er nicht.

Dann gibt es ja noch den VoodooTSCSync.Kext. - Das Einbauen war nach meinen Erinnerungen so kompliziert, dass ich damals den TSCAdjust genommen hatte.. Und ich hab keine Anleitung dafür gefunden, sorry!

Oh, ich sehe grade im Readme im aktuellen Download:

Also noch ein Versuch? Ist aber auch schon von 2018. Versuch macht Kluch..

Wie geht es jetzt weiter?

Ich hab über meinen X99er-OC-Aufbau-Thread zu meinem Glück auch ein paar Entwickler angesprochen und Leute, die sich mit den Entwickler-Seiten auskennen. Und da bin ich dann auf eine Dortania-Aktualisierung des CpuTscSync.Kext gestoßen worden, bzw. eigentlich drei:

Erste Erkenntnis: Ich bin nicht allein! Andere haben das Problem anscheinend auch!

Also den AppleXcpmExtraMsrs-Quirk gesetzt - und leider keine Auswirkung bei mir!

Dann gibt es zum CpuTscSync ein ergänzendes BootArg: TSC_sync_margin=0

Hat bei mir einen Tag gehalten, aber kaum wollte ich mit Photoshop arbeiten...

Der dritte Hinweis von cobanramo betrifft dann eine neue ganz aktuelle Kext-Version 1.1.1

Liest sich ja erstmal ganz prima, Problem gelöst?

Eigentlich kann ich mir kaum vorstellen, dass die Skylake-X-CPUs in Apples iMacPro laufen, nicht aber im Hackintosh. Gut, meine Skylake i9/9900x gibt es nicht im iMacPro, ist aber doch sehr nah dran am W2150b.

Als MacPro7,1 hat auch der neue Kext sowohl in Clover als auch in OC nicht wirklich geholfen.

Dann hat mich mimixa auf einen (älteren) UEFI-Patch für das BIOS hingewiesen. Und mir diesen auch ins BIOS eingebaut.

Der kommt mir sinnvoll vor, ich weiß aber, dass ich für das 4-stellige BIOS irgendwas in meiner EFI grundlegend ändern musste, weiß aber nicht mehr, was das war.. Also hab ich immer noch nicht geflasht.

Im Moment läuft der 299er wieder als iMacPro über OC 1.0.2. Mit dem neuen Kext. Bisher absturzfrei, aber bis auf dieses Internet-Schreiben hier auch ohne Last und ohne Last-Veränderungen. Hatte ich schonmal am Anfang der Probleme erfolglos getestet mit dem alten Kext.

Hat gehalten vom Vormittag bis um 16:18 h. Also wieder nichts, das aber über 7 Stunden lang..

18:50h: Neuer Start, neues Glück?

Ich bin durch diverse andere Threads darauf gekommen, dass bei meinem dreistelligen BIOS wohl die AWAK-Fix.SSDT nicht notwendig ist.

Auf jeden Fall ist der MacPro7,1 erstmal ohne gestartet.. Wenn das der einzige Haken wäre, könnte ich ja problemlos das BIOS updaten..

Wenn das hilft mit dem AWAK-Fix und dem neuen BIOS..

Ohne hat er jetzt wieder nur bis 21:13h gehalten, also nichtmal 2 1/2 Stunden. Vielleicht kann ja unser alter X299er-Experte Tastenheld sehen, wo der Fehler steckt..

Ja, das ist schon verrückt: jetzt läuft seit dem letzten Absturz schon seit über 4 Stunden der Bench-Test Unigene Heaven in Dauerschleife. Da sorgen CPU und Vega FE mit ihren Wasserkühlungen für ne gute Zimmerheizung gemeinsam mit dem Bildschirm. Und läuft, und läuft. Dauer-Score knapp 2200 Punkte, FPS zwischen 40 und 175. Auch im zehnten Versuch hintereinander. Da wird auch nichts ZU WARM, für solche Film-Rendereien wurde er ja mal geplant.. Gut, das sind keine Metal-Berechnungen, aber trotzdem eben Last. Nur ohne großes auf und ab. Ich versteh es nicht!

Mit dem neuen Kext, als MacPro und jetzt ohne AWAK-Fix.

Gegen halb 7 ist er doch wieder eingefroren. Und ich hab den Absturzbericht gelöscht, statt ihn zu sichern..

Vielleicht hast Du recht, bluebyte , was den X99er angeht. Das ist eine Diva. Den hatte ich ja auch schon gegen den 299er ausgetauscht. Lustiger Weise hab ich seit vielen Jahren einen Asus X99 A2 als Firmenrechner, also fast das gleiche Board. Nur mit einer älteren (!) Haswell-CPU und einer einfachen Nvidia 1060. Viele Macken haben die gemeinsam, trotz Win10 gegen macOS.

Aber der 299er, um den es jetzt hier geht, der war eben die letzten Jahre mein Arbeitstier. Ein Rennpferd beim Spazierengehen zwar, aber jeden Tag zuverlässig am Start. Seine Macken mit den Abstürzen hat dieses Rennpferd erst seit macOS 15 beta 8 (24A5331b).

Ab dem Update hatte der X99er den scheinbar gleichen Fehler, der sich dort als störender TSC-Sync-Kext herausgestellt hat. Auch mit dem leider fast zeitgleich upgedateten macOS Sonoma 14.6. Vorher und auch jetzt bei allen älteren Systemen hatten diese Kexte nie gestört, auch wenn sie nicht notwendig waren. Und der X299er läuft ja auch mit Ventura weiter als zuverlässiges Renn- und Dienstpferd.

Da der neue Kext keine wirkliche Verbesserung der Situation bewirkt, sehe ich jetzt zwei Möglichkeiten:

entweder schmeiße ich die SSD-Festplatte raus, auf der jetzt Sequoia läuft und ersetze sie durch eine NVMe.

Die dann wiederum meine Samsung-NVMe mit macOS 10.15.7 ersetzen sollte. Endlich genug Platz, denn jetzt ist es eine 250er.

Das erfordert aber eine Menge Umbau-Arbeit, denn sowohl NVMe's als auch SSDs sind gut versteckt eingebaut. Das ist was für Regentage..

Komplette Demontage. Blöd gemacht..

Oder ich teste doch noch das neue BIOS. Könnte mir damit aber den Rechner zerschießen oder zumindest lahmlegen.

Flashback gibt es. Nur ist der Knopf dafür doch etwas verbaut:

Und ausgerechnet über diesen Port mit USB2 läuft jetzt grade mein Backup der Sequoia-Platte..

Das alte BIOS ist geladen, der USB-Stick mit dem neuen bereit. Muss ich nur noch die alten Einstellungen sichern. Und hoffen, dass wirklich nur der AWAK-Fix fehlt. Ist denn von den HEDT-Spezialisten Tastenheld oder apfelnico morgen mal jemand online? Gut, Urlaub geht vor..

Auch das Backup ist fertig, zwei Startplatten sind auf eine 2-TB-NVMe umgezogen. Und ich hab den freien Nachmittag draußen verbracht.. Brr, kalt!

Jetzt heißt es: alles abziehen, was geht - und dann das neue BIOS drauf. Backup auf das alte BIOS ist auch vorbereitet, für alle Fälle.

Bei jedem macOS-Start zickt das BR/DVD-Laufwerk rum. Muss wohl auch noch ab.

Wie kann man einen wichtigen Schalter nur so versteckt einbauen??

Zwischendurch meldet sich noch vor dem BIOS die Hardware mit einer ungewohnten Meldung:
"HDA: Controller reset - Time Out" über den sonst leeren Schirm. Was ist das?

Momentan läuft der Rechner wieder, scheinbar stabil:

Erstmal gab es einen Gang durch die Hardware: Grafik gegen das baugleiche Gegenstück gewechselt, die uralten (Samsung)-System-SSDs und NVMe's raus und den Inhalt auf eine größere gepackt, Steckverbindungen geprüft, ...
AWAK-Fix hab ich deaktiviert - brachte keine Veränderung, auch der Start ging weiterhin.

Lief dann immerhin 20 1/4 Stunden bis zum nächsten Absturz.

Dann hab ich im BIOS meine Einstellungen extern auf USB gesichert und über Flashback das von mimixa überarbeitete aktuelle 4001er BIOS aufgespielt.

Und dann:

Äh, ja. Statt einer im BIOS ausführbaren Datei, wie ich es sonst kenne, wurden die Einstellungen als .txt-File gespeichert. Das stellt nichts ein. Ist aber lesbar. An langen Winterabenden.

Also das BIOS grob nach Gedächtnis wieder eingestellt. Allerdings bin ich spätestens bei den zig Einstellungen für Thunderbolt wirklich am Verzweifeln: Brauch ich das, stört diese Einstellung oder hilft sie? Gut, Hotplug ist erstmal wieder Geschichte, hatte für die Grafik-Box auch nie funktioniert.

Der Rechner-Start ging erstmal nur bis direkt nach die Festplatten-Auswahl in OC.

Dank griven 's Entdeckung im Dortania-Guide zwei Quirks abgeschaltet.:DevirtualiseMmio -> DisabledSetupVirtualMap -> Disabled (Sollte speziell bei X299 auf neuerer Firmware disabled sein laut Dortania, weiter oben steht das noch anders)

Vier Augen sehen einfach mehr als zwei, hab ich glatt überlesen. Und auch bei Dortania ist ein Guide nicht in Stein gemeißelt, sondern kann sich durchaus verändern. Jetzt läuft die Kiste, und wenn es TSC-Timing-Fehler gab, sind die mit dem neuen CpuTscSync-1.1.1 (Danke an cobanramo ) und dem gepatchten BIOS behoben.

Danke an mimixa , griven , cobanramo und apfelnico für die Hilfe.

Jetzt muss ich noch eine Merkwürdigkeit aus BIOS, Einstellungen & Hardware aussortieren: die USB3-Ports in der Rückseite müssen leer sein, sonst gibt es keinen Start, nichtmal ins BIOS.

Du hast recht, hatte ich völlig vergessen..

Unter Clover funktioniert es schon mal. Da geht das Ausschalten ja risikolos "on the fly"..

Und mit OC auch. Der Patch wirkt also!

Nur an den Einschlaf-Abstürzen ändert das nichts. Ich muss mich da wohl mal um KASLR kümmern. Das ist ja auch noch möglich - und kann derartige unspezifische Fehler verursachen, besonders bei X99er, X299er und Z390er Boards. Na, prima..