Kernel panics nach Aufwachen trotz darkwake

  • Hallo liebe Gemeinde,


    Ich bin vor einigen Tagen von Clover auf Ozmosis umgestiegen mit dem hier geposteten EFI-Image. Ozmosis ist ein wenig bockig was das interne Boomten angeht (bisher hat das Halten von Pos1 bzw Home erst einmal geglückt, aber es gibt ja noch F10), aber sonst läuft und lief alles problemlos. Hardware sollte in der Sig sein.


    Ich habe einzig weiterhin ein Problem mit dem Sleep. Wenn ich den Computer einige Zeit alleine lasse, aber auch gelegentlich so beim Aufwecken startet er stattdessen neu. Das Problem hatte ich auch mit Clover allerdings hat's da keine Kernel panic hinterlassen, warum auch immer.


    Eigentlich deuten die Symptome auf ein Problem mit PowerNap hin, wenngleich mich das eigentlich verwundert, da der Punkt nicht in den System Preferences auftaucht und ich diesen Test (der Hack ist bislang nur Spielzeug) auch nicht auf einer SSD installiert habe. Dennoch habe ich Ozmosis mal darkwake=0 und auch darkwake=8 ins NVRAM schreiben lassen, hat aber nichts gebracht. Ich bin ehrlich gesagt irritiert, dass es mehr als nur zwei Schalter für darkwake gibt und auch was die anderen Zahlen jeweils bedeuten. Sollte ich noch andere Werte probieren?


    Als weitere Bootargumente habe ich noch slide=0, wobei ich mich da Frage, was das eigentlich genau macht, es wird nur immer oft geschrieben, man solle es bei Power-Management-Problemen ausprobieren.


    Hat jemand noch Vorschläge, woran es liegen könnte bzw. was ich ausprobieren könnte? Als SMBIOS habe ich momentan einen iMac 14,2 eingestellt. Im Anhang ist die Kernelpanic


    Vielen Dank!


    PS: Ich habe noch zwei weitere kleinere Fragen: 1) Ist das Kernelpatchen für Haswell eigentlich noch akkut (dass, das man in Clover mit der KernelPM-Option on-the-fly machen kann)? 2) Sehe ich richtig, dass Ozmosis nur die "neuen" 17-stelligen MLB-Nummern unterstützt? Habe hier versucht, ne alte 13-stellige einzutragen, aber Ozmosis füllt sie immer wieder auf 17 Stellen auf. Kann man das ändern?


    Gigabyte GA-H81m-HD3 - i3-4150 - EVGA GTX 760 - 8 GB RAM - BCM94360CD - 10.10.1 - Ozmosis 1479

  • Hum also erstmal zu den einfacheren Fragen :)


    Slide=0 unterdrückt eine bestimmte Virtualisierungstechnik und entspricht im großen und ganzen der VT-d disabled Einstellung im Bios. Hat man slide=0 als Bootarg gesetzt kann man VT-d im Bios aktiviert lassen ohne Gefahr zu laufen, dass sich der Rechner komisch verhält. Was die MLB Werte angeht zitiere ich hier einfach mal aus dem changelog zu OZM894M

    Code
    1. Ensure 'MLB' variable >= 17 digits, pad BaseBoardSerial with digits generated from UUID when needed.

    Demnach ja, es unterstützt nur die 17 stelligen MLB´s und nein man kann dieses absolut dämliche Verhalten leider nicht beeinfluss. Gerade mit Blick auf die aktuellen Entwicklungen rund um iMessage und Facetime war das eine absolut dämliche Entscheidung...


    So nun aber mal zu dem PowerManagement Themen. OS-X verfolgt beim PowerManagement seit Mavericks zwei unterschiedliche Strategien. Für CPU´s > IVY Bridge gilt nach wir vor der klassische Weg über die AppleIntelPowerMangement.kext ab IVY Bridge ist das Powermanagement in den Kernel verlagert worden (Stichwort XCPM) und genau hier liegt der Hase sprichwörtlich im Pfeffer. Setzte ich ein System mit einer IVY Bridge oder Haswell CPU ein versucht der Kernel zuerst das XCPM zu starten was aber in den meisten Fällen fehlschlägt weil die SSDT Tabellen im Bios nicht zu den Anforderungen der PM Implementation von Apple passen das Resultat ist ein Fallback auf die alte Variante mit AppleIntelCPUPowermangement.kext soweit erstmal nicht weiter schlimm, aber...


    Die AppleIntelCPUPowermanagement.kext versucht ein bestimmtes Register in einem normalerweise geschützten Bereich zu beschreiben und scheitert daran, da der Bereich eben geschützt ist (Stichwort locked MSR-2 Register) es kommt zu einer Kernelpanik. Bootloader wie Clover setzen an der Stelle auf einen (genau genommen sogar 2 patches) patch um dieses Verhalten zu unterbinden erkauft wird das jedoch mit einigen Problemen sowohl beim Speedstep als auch beim Sleep/Wake. Die Lösung ist, zumindest unter Ozmosis, relativ einfach. Starte OSX und öffne Dir ein Terminal und gib den folgenden Befehl ein

    Code
    1. curl -o ~/ssdtPRGen.sh https://raw.githubusercontent.com/Piker-Alpha/ssdtPRGen.sh/master/ssdtPRGen.sh

    bestätige alle eventuell auftretenden Fragen mit JA. Sobald alles erledigt ist geht es mit dem folgenden Befehl weiter

    Code
    1. chmod +x ~/ssdtPRGen.sh

    Anschließend musst Du nur noch

    Code
    1. sh ssdtPRGen.sh

    eingeben. Das Ergebnis ist eine ssdt.aml auf dem Desktop. Diese kopierst Du jetzt auf Deine EFI Partition in den Ordner /EFI/OZ/Acpi/Load und gibst anschließend noch -xcpm mit in die BootArgs um das korrekte Powermanagement für Deine CPU zu aktivieren.

  • Danke für die ausführliche Antwort.


    Dass mit der MLB ist natürlich eine dämliche Entscheidung von Seiten der Entwickler. Aber da es bereits in der 894er Version gemacht wurde, war das Problem mit den MLB-Checks möglicherweise noch nicht akut, dass müssen Leute beurteilen, die schon länger dabei sind. Möglicherweise kommt die Funktion ja wieder zurück.


    iMessage ist auch erst einmal nicht so wichtig wie funktionierendes Power Management.


    Zitat

    Slide=0 unterdrückt eine bestimmte Virtualisierungstechnik und entspricht im großen und ganzen der VT-d disabled Einstellung im Bios. Hat man slide=0 als Bootarg gesetzt kann man VT-d im Bios aktiviert lassen ohne Gefahr zu laufen, dass sich der Rechner komisch verhält.

    Ich dachte, dass dart=0 den VT-d Kram unterdrückt, wo ist der Unterschied?


    Dass mit der SSDT hatte ich glatt vergessen. Hatte vorher für Clover bereits eine erstellt mit dem verlinkten (ver-curl-ten :?) Script, aber gedacht, sie wäre bei Ozmosis wegen der gepatchten DSDT nicht notwendig. Macht allerdings Sinn, da ein Teil der SSDT ja CPU-spezifisch ist. Durch die SSDT und den Kernelparameter -xcpm habe ich nun folgende schöne Kernel Messages:


    Code
    1. 20/01/15 20:06:54,000 kernel[0]: XCPM: registered20/01/15 20:07:21,000 kernel[0]: IOPPF: XCPM mode



    Vorher hatte ich nur die erste Zeile. Wobei sich hier für mich die Frage stellt, wozu -xcpm nötig ist. Als Vorsichtsmaßnahme? Ich meine, sollte der Kernel nicht automatisch xcpm benutzen wenn ein Haswell-Prozi genutzt wird?


    Gebracht hat das ganze übrigens nichts, leider. Die selbe Panic wie zuvor. Ich habe allerdings keine darkwake-Parameter übergeben. Sie tritt auch wie gesagt nicht immer auf, sondern unregelmäßig. Dieses Mal jedoch trat das Problem auf, nachdem er von allein aufgewacht ist, siehe Log.




    Der Computer hat also knapp 2 Stunden geschlafen, wacht wegen Maintenance auf und der letzte Eintrag dazu ist dass die Wifi-Karte sich schlafen legt. Beim nächsten Aufwachen erfolgt dann der Reboot.


    Ist es normal, dass nach dem darkwake keine Einträge über das Wiedereinschlafen gemacht werden, von der Wifi-Karte abgesehen? Meint ihr es wäre einen Versuch wert, die Karte mal probeweise auszubauen und zu schauen ob's kurioserweise daran liegen könnte?


    Noch weitere Ideen, was ich machen könnte? Hier ist noch das boot log. Soll ich sonst noch einmal die Ausgabe von IOReg zur Verfügung stellen, würde das helfen?

    Dateien

    • boot.log.txt

      (16,87 kB, 72 Mal heruntergeladen, zuletzt: )

    Gigabyte GA-H81m-HD3 - i3-4150 - EVGA GTX 760 - 8 GB RAM - BCM94360CD - 10.10.1 - Ozmosis 1479

  • Hallo Slurp


    bist du schon einen Schritt weiter gekommen?


    Ich habe genau das selbe Problem, allerdings mit anderem Mainboard / CPU
    aber vermutlich der gleichen WLAN/Bluetooth-Karte.


    Zumindest ist die letzte Meldung auch:
    20/01/15 19:43:07,000 kernel[0]: ARPT: 4419.166010: wl0: powerChange: *** BONJOUR/MDNS OFFLOADS ARE NOT RUNNING.



    Gruss
    Pumuckl

    Aktuell:

    Asus Prime Z490-P | i9-10850K | Radeon RX570 | OpenCore | Monterey


    Vergangenes:
    Asus Prime Z270M-Plus | i7-7700K | Radeon RX 570 | Clover / Catalina 10.15.4


    Asus B150 Gaming Pro | i7-6700 | Radeon RX 570 | OpenCore / Catalina 10.15.4

  • Nein ich bin nicht weiter. Ich habe auch keine Ideen mehr, was ich noch probieren sollte. Habe die Karte probeweise ausgebaut, aber das war eher Voodoo. Habe nicht geglaubt dass dass was bringen wird.


    Das Problem scheint eher immer noch ein PowerManagement-Problem mit dem Kernel zu sein.

    Gigabyte GA-H81m-HD3 - i3-4150 - EVGA GTX 760 - 8 GB RAM - BCM94360CD - 10.10.1 - Ozmosis 1479

  • Hum verdammt, im Eifer des Gefechts mal wieder dart und slide durcheinander gebracht, Schande über mich...


    Du hast natürlich recht, dart ist für die VT-d Geschichten, Slide gibt ein offset an um die Basis Adresse an die der Darwin Kernel geladen wird zu verschieben. Nötig ist Slide unter bestimmten Umständen wenn OSX mit einem UEFI Bootloader (Clover oder Ozmosis) geladen wird und dazu eine bestimmte UEFI Variante zum Einsatz kommt. In dieser eher seltenen Kombination versucht OSX den Kernel an einer Speicherstelle einzunisten die über die Firmware geschützt ist, das Ergebnis ist ein Kommentarloser neustart des Rechners. Slide=0 verschiebt diese Adresse in einen unkritischen Bereich.

  • Servus!


    Gibts zu dem aufwachen/Kernel Panic - Dingens schon eine Lösung?


    Gruß
    Kellni

    Einmal editiert, zuletzt von masterkellnicom ()

  • Wenn alles sauber eingestellt ist und das Powermanagement richtig läuft gibt es mit dem Aufwachen eigentlich keine Probleme mehr. Wichtig ist hierbei, dass man das Powermanagement von OS-X richtig versteht. OS-X unterscheidet zwischen 2 Strategien für das Powermanagement während in OS-X <= MountainLion und bei CPU´S <= Sandy Bridge das klassische Powermanagement über die AppleIntelCPUPowerManagement.kext geregelt wird gilt für Prozessoren > SandyBridge und OS-X ab MountainLion das neuere Kernel getriebene XCPM (Xnu CPU Power Management) was für Haswell per default aktiv ist und für IvyBridge per kernelflag (-xcpm) optional aktiviert werden kann. Voraussetzung für einen reibungslosen Betrieb ist in dem Fall aber eine passende SSDT.aml (kann über ssdtPRGen leicht erstellt werden).

  • Servus!
    Sollte nicht Clover an sich schon alles richtig einstellen was ssdt angeht?


    Danke für die Aufklärung Dart/Slide :) Wieder was gelernt.


    Was passiert eigentlich wenn VT-d bzw. dart= 0 nicht gesetzt ist?


    Dank im Voraus
    Kellni

  • VT-d bezieht sich auf die Intels Virtualization Technology

    Gruß CrusadeGT


  • Wozu s gut ist hat der Griven weiter oben schon erklärt...


    Was ich wissen wollte war was beim Hack passiert wenns nicht deaktiviert ist...


    Gruss Kellni

  • war bisher nie gesetzt (beim 4770 k lässt sichs im bios ja nicht deaktivieren).


    Kernel Panic beim Start auch nie - halt der ab-und-zu-aufwach-fehler wie beim ersten Post oben beschrieben...


    Happy hacking
    Kellni

  • Leider stellt Clover eben gerade mit Blick auf die SSDT nichts wirklich richtig ein. Die Optionen um P und C-States generieren zu lassen passen zur Core2 Cpu Generation aber eben nicht mehr zu den Core I Cpu´s will man hier ein vernünftig unterstütztes Powermanagement muss man selbst Hand anlegen. Glücklicherweise ist das ja dank ssdtPRGen keine große Sache. Einfach das tool ausführen und die entstandene ssdt.aml in den Ordner /EFI/Clover/ACPI/Patched legen und gut ists ;)

  • Sodele... Nun hab ich das auch noch ausprobiert - spackt immernoch rum.


    Ich denk so langsam es ist der Speicher - wobei ich da nun auch schon zweierlei ausprobiert habe (Kingston und im mom. Corsair).


    Nun versuch ichs nochmal mit Crucial und wenn das nix hilft geh ich (nochmal) auf ein anderes Board.
    Ein ASUS sollte ja auch ohne Probleme zu hacken sein oder?


    Gruß
    Kellni

  • Gigabyte hab ich schon drei verschiedene durch...


    GA-Z87N-WIFI, GA-Z87N-WIFI Rev. 2.0 und im Moment ein GA-Z97N-WIFI... Soll ich mir nochmal ein anderes kaufen??
    Das einzige das in meinen Schorsch reinpasst wäre noch das Gaming-Dingens.


    Alles was irgendwer/irgendwo an tipps und tricks hatte hab ich probiert - sogar einen ausflug in die OZ-Welt hab ich gemacht!
    Prozzis hab ich auch zwei verschiedene probiert, drei verschiedene Netzteile und wie oben geschrieben zweierlei Speicher.
    Letztens gabs sogar unter WinDOS einen bluescreen (hab ich eine ganz nackte installation nur zum Wolfenstein daddeln :).


    Also noch der Versuch mit Crucial-Riegeln. Wenns dann noch net klappt geh ich auf ASUS und schau was da passiert.


    Liebe Grüße
    Kellni

  • griven

    Hat das Label Erledigt hinzugefügt