Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Um ehrlich zu sein habe ich seltenst solche Probleme. Die meisten meiner Hacks benutze ich beinahe produktiv, mache regelmäßig Backups, halte die Daten auf zwei NAS und gut is. Der zuständige NUC läuft Tag und Nacht ohne Absturz seit Monaten. Bin soweit zufrieden.
Aber anders: Frei nach dem Motto "ich hätte gerne ein Problem" müsste man nicht die Kext laden, diverse RTC-Fixe deaktivieren und dann mal schauen, ob es stabil läuft oder? So ist man ständig mit 128Byte unterwegs, richtig?
Früher war es Gang und Gebe die zweiten 128 zu deaktivieren, das kannst du also probieren.
Wie genau ergibt sich das von dir geschilderte "richtige Vorgehen"?
das hatte ich jetzt aus den Links so identifiziert, anscheinend war ich aber schon zu müde 
was ist denn der richtige Weg - einfach nur per SSDT die Größe auf 0x1 limitieren? da sind mir die Zusammenhänge ehrlich gesagt nicht so klar.
Ich glaube da gibt es kein richtig oder falsch, Frage ist eher was du genau machen und damit erreichen willst. Wenn du den RTCMemoryFixUp-Weg gehen willst, dann macht es Sinn erstmal die zweite Bank komplett per Bootarg zu exkludieren.
Was hat die SSDT bewirkt? Wie gesagt, du kannst auch mit RTCMemoryFixUp arbeiten.
An den Logs hab ich nichts interessantes gefunden, was meintest du?
ich hab's doch mit dem RTCMemoryFixup gemacht und Folgendes hinzugefügt: rtcfx_exclude=80-FF
bisher kein Absturz, aber ich warte noch 
Das ist schonmal ein gutes Zwischenergebnis! Reproduzierbare Abstürze wären in dem Kontext natürlich praktisch, vielleicht findest du ja noch was...
Ich glaube irgendwas stand dazu auch in dem Issue auf Github, aber da müsste auch ich nochmal nachlesen. Kannst es aber ja mal ausprobieren, wenn es erfolgversprechend sein könnte. Auch ein TSC Sync kann erfahrungsgemäß manchmal bei sporadischen Wake-Abstürzen helfen.
Tut mir leid, ich habe aktuell nicht die Zeit dem Problem in tiefe nachzugehen. Vielleicht hat ja noch jemand anderes eine Idee.
Wenn das Problem seit 10.14 und nicht erst seit 10.15 besteht, liegt der Checksum Verdacht nicht mehr ganz so nahe. Wurde nach deinen Versuchen die zweite Memory Bank zu deaktivieren im Verbose Boot log eine Meldung angezeigt, dass nur 128b of Memory zur Verfügung stehen? Hast du mit RTCMemoryFixUp mal die erste Memorybank in die Mängel genommen, mal HibernationFixUp und mal einen TSC Sync ausprobiert? Ist der HibernateMode auf 0? Hast du mal versucht das SleepImage schreibzuschützen? Lässt sich im Sleeplog inzwischen was interessanteres erkennen? Mehr fällt mir dazu gerade nicht ein, ohne umfangreicheres Debugging, was aber bei Sleep nicht Ohne ist.
ja 
der Post war gestern noch nicht fertig..
Ich hab gestern weitere Unterschiede zwischen den beiden Systemen und in den DSDTs diesen Unterschied gefunden. Ich tippe mal, dass das PCIE-Wiring (der MFF hat keine PCI-Slots) ein anderes ist. Hab mich jetzt gefragt ob es die Speicherbereiche/Adressen sind, die ein Problem verursachen. Aber ob man hier was ändern kann und sollte - keine Ahnung?
Zusätzlich hab ich mal die ioreg-Dumps verglichen, da zeigt sich aber kein großer Unterschied.
Ich habe auch eine OPTIPLEX 3070 MFF und bis Big Sur hatte ich auch bei dem Sleep keine Probleme aber dem Update auf Big sur habe alles versucht aber der Sleepmode funkt nicht. Du bist da weiter komplexer an die Sache ran aber ich sehe eigentlich, dass es ein generelles problem in DELL Rechnern ist. Eine Lösung gibt es bestimmt aber mit so einer komplexen Zusammenhang hatte ich nicht gerechnet.
