Beiträge von hanspeteroliver

    Hackintosh-Info.de Mein BIOS kann ich gerne teilen - auch wenn ich nicht sicher bin, ob dir das was bringt. (Das B860-A BIOS ist übrigens marginal anders, als das Z890; bspw. kein Per Core Control & Cfg Lock kann nicht 'einfach' deaktiviert werden)
    Die meisten Einstellungen habe ich für eine saubere Diagnostik nur provisorisch (und tbh ohne Konzept) gesetzt (maßgeblich hier eig. nur Package Limit C-State C0/C1), und bisher noch nicht wieder zurückgeändert, da ich dann erst die Auswirkungen/Stabilität ausführlich testen wollen würde.

    Ich hänge seperat noch ein Diff an mit den spez. Änderungen der letzten 24h an - das liefert vielleicht ein Bild, das leichter nachzuvollziehen ist. Beim Diff habe ich jetzt erst bemerkt, dass ich beim Testen wohl doch den Großteil der BIOS Tweaks wieder zurückgestellt habe ^^ VT-d ist irrelevant, da in meiner config.plist DisableIOMapper true ist.
    Aktive kexts sind: Lilu, VirtualSMC, AppleMCEReporterDisabler, RestrictEvents, USBMap (in Sonoma Transplat erstellt), CpuTopologyRebuild (weiß nicht wirklich ob notwendig, hab's beim Testen reingenommen um deiner config näher zu kommen und behalte es vorerst. Das Gegenteil gilt für NVMeFix, das hat den Fehler bei mir eher maskiert und das System läuft stabil(er) ohne, wenn vielleicht auch ohne PM)

    Dateien

    • biosDump1302261330.txt

      (32,21 kB, 308 Mal heruntergeladen, zuletzt: )
    • diff.txt

      (816 Byte, 29 Mal heruntergeladen, zuletzt: )


    Hallo zusammen & danke für den Report Hackintosh-Info.de (ich war sehr erleichtert, als ich jemanden mit dem gleichen Fehler & auch noch gleichen Hardware Profil gefunden habe).

    TLDR: Gleicher Fehler, ähnliches Board, gleiche Konfiguration. Fix für mich: SetupVirtualMap->False, RebuildAppleMemoryMap->False, SyncRuntimePermissions->False, EnableWriteUnprotector->True (bei ersterem ist nicht isoliert getestet, ob notwendig)

    ---

    Die Installation auf meinem Asus Rog B860-A "Gaming Wifi" war schon sehr holprig und ich war enttäuscht, als das System nach anschließend doch erfolgreicher Installation+Boot auf der NVMe ständig einfror, während der vom Haswell transplantierte Tahoe-Hack (auf SSD tho) ohne Probleme lief. Deine Methode Chris, mittels CleanMyMac "Free RAM" den Fehler zu provozieren ist zwar ungewöhnlich, jedoch kreativ pragmatisch & hat mir letzlich beim initialen Troubleshooting gut gedient. Nachdem ich etliche BIOS Einstellungen und kext configs angepasst habe, ist das Problem seltener aufgetreten, CleanMyMac "Free RAM" lief sogar mehrere Male problemlos durch. Ich wollte es aber wissen und habe "stress --vm 20 --vm-bytes 1G --timeout 300s" (auch hier etliche Variationen, mal 3x8G, mal 20x1-1.2G, mit & ohne --vm-hang=allesnurnicht0) gefeuert, und da war es wieder. Ich habe erst wie Mieze auch gemutmaßt, es sei ein DMA Problem, habe aber festgestellt, dass ich weder einen DMAR Table eingeladen habe, das Problem unabhängig von VTD auftritt (wie ihr bereits festgestellt habt) & in Linux auch überhaupt keine Reservierung für die page area 0x18* oder sonstige Hardware ab 0x100000000 zu finden ist; free for all. Ich habe an diesem Punkt bereits so viele Quirks und BIOS Einstellungen geändert, dass ich selber den Überblick verloren habe und mir zwecks Dokumentation an einem langweiligen Sonntag sämtliche Diffs der Snapshots durchgehen darf. Das System selbst lief an sich zwar stabil und ist nur bei meinen synthetischen Stresstests eingefroren. An diesem Punkt hört man wohl dann im Normalfall auf.

    Auffällig schien mir aber, dass es bei mir auch die page 0x180009000 war (+- 64K abweichung). Obwohl das B860-A dem Z890 durchaus ähnlich ist, hatte ich hier ja eher einen OpenCore, Kext oder (unwahrscheinlich) Kernel Bug in Vermutung; Software. Ich habe gedacht, ich reserviere den Bereich in der config.plist einfach vorsorglich 1M vor und nach 0x180000000 und hab meine Ruhe. Hat leider nichts gebracht, vielleicht findet "RebuildAppleMemoryMap" statt, nachdem OpenCore gegebene Memory Regions als *Type* reserviert. Wenn es nicht halb 4 nachts wäre, hätte ich das mit Debug OC zwar gerne bestätigt, habe es also in Verzweiflung einfach mal blind ohne RebuildAppleMemoryMap probiert. (Wichtig: Dazu muss dann allerdings auch SyncRuntimePermissions de- und EnableWriteUnProtector aktiviert werden, sonst kernel panic im early boot)
    Und siehe da: ES LÄUFT. Und wie! 20 worker, die je 1G+ full-pressure reallocaten & freimachen, währenddessen kann ich Cinebench starten UND CleanMyMac RAM "frei" machen, so oft ich will. Ich habs bisher nicht mehr gecrasht bekommen! Was RebuildAppleMemoryMap nicht zu benutzen für Auswirkungen hat, wenn ich ansonsten soweit booten kann, muss ich wohl ein anderes Mal näher erforschen.

    Entschuldigt den kleinen jap. Hatte keine Zeit, mich kurzzuhalten.

    P.S.: Bei Interesse & richtig stehender Mondphase teile ich gerne ein bisschen "dokumentierter" meinen Weg auf diesem speziellem Board mit Arrow Lake - dafür muss ich aber selber erst ausführlicher testen!