Sequoia-iMacPro1,1 - Boot-Arg „-no_compat_check“ nötig nach OCLP-Root-Patches, schlimm oder nicht?

  • Hier einmal die EFI :) Also nur nochmal zur Wiederholung, das aktuelle Problem ist, dass nach den OCLP-Root-Patches (es werden nur die WIFI-Patches angewendet) ohne das boot-arg "-no_compat_check" macOS nicht booten möchte und der 🚫-Fehler angezeigt wird.

  • Und dann hast Du noch gleichzeitig die Bootargs -amfipassbeta und amfi=0x80...

    Das Bootarg -amfipassbeta benötigt man aber auch nicht zwingend oder? Bei meinem läuft das nämlich nur mit dem amfipass.kext.


    Dav1310 Sehr interessant, auf jeden Fall danke dafür. Ich habe mir den Tread jetzt ein paar mal durchgelesen und habe jetzt folgendes gemacht:
    1. Via ControlMsrE2-Tool den CFG-Lock-Status überprüft. Heraus kam "This firmware has UNLOCKED MSR 0xE2 register!". Daraufhin habe ich die Quirks "AppleCpuPmCfgLock" (zwischenzeitlich aktiviert, da ich nicht wusste das CFG bereits deaktiviert war) und "AppleXcpmCfgLock" deaktiviert.
    2. Den Quirk "AppleXcpmForceBoost" ausprobiert.

    Hast du die Benchmarks mit MacPro und iMacPro und "AppleXcpmForceBoost" durchgetestet? Meine CPU ist übertaktet. Wahrscheinlich kommt der Unterschied daher. Im Bios hast Hyperthreading aktiviert? XMP für RAM aktiv?

    ich kann gleich oder morgen mal schauen, wie die Benchmarks ohne Übertaktung aussehen nur mit dem Standard ASUS Profil

  • Noch eine Anmerkung bzgl. GeekBench. Ich habe gerade mal auf GeekBench 6 geupdatet und nun ist der Score "besser": https://browser.geekbench.com/v6/cpu/17139789
    Man kann halt nicht Birnen mit Äpfeln vergleichen...

    Dav1310 Zeitlich bedingt habe ich bis jetzt nur den iMacPro1,1 getestet. Aber bzgl. des Scores siehe mein Zitat - das ganze hat sich so gut wie erledigt, da ich vorher mit GeekBench 5 getestet hatte und somit GeekBench-5 und GeekBench-6 Ergebnisse verglichen habe. Vorausgesetzt du hast tatsächlich Geekbench-6 genutzt?
    AppleXcpmForceBoost scheint allerdings erst einmal keinen direkten Leistungssprung zu schaffen, wie es bei demjenigen im dem von dir verlinkten Thread war. Morgen werde ich auf Win11 einen einmal GeekBench laufen lassen und dieses Ergebnis dann als Referenz nutzen. Hyperthreading und XMP-Profil sind selbstverständlich aktiviert, sonst wäre die Kiste wahrscheinlich langsamer als manch Laptop:kichern:

    Spricht eigentlich etwas dagegen das boot-arg "-no_compat_check" weiter zu verwenden, da ich die Ursache für den Fehler ohne boot-arg nicht finden lässt? Einzig und allein nach dem Login brauch die Kiste ein wenig bis Wallpaper + Anmeldeobjekte geladen/geöffnet werden, aber das wird damit wahrscheinlich nicht zusammenhängen.

  • Flynn_LG Ich habe jetzt gerade zwei Benchmarks laufen lassen. Die Version ist 6.6.0. Anscheinend haben die da was geändert, weil die Scores grundsätzlich höher ausfallen


    Einmal die Stocksettings

    Und einmal übertaktet


    Wie in dem anderen THread beschrieben benötigte ich "AppleXcpmForceBoost" auch nur mit dem MacPro7.1 smbios. Ohne diesen Quirk wurde bei mir immer nur der Basistakt 3,6ghz) der CPU genutzt. Beim iMacPro smbios benötigte ich diesen Quirk nicht, da die CPU auch ohne diesen Quirk den Turbotakt (4,9ghz) erreichte. Da ich diesen Quirk aber vermeiden wollte, was auch im Opencore Manual beschrieben steht, nutze ich seither das iMacPro smbios. auch weil alle Benchmarks, egal ob Lexmark, Cinebench oder Geekbench durch die Bank weg besser waren.


    Es wäre interessant wenn du die Benchmarks mit dem MacPro smbios nochmal zum vergleich machen würdest, wenn du Zeit findest.


    Und bei dem no-compat-check kann ich dir leider nichts gutes zu sagen, das Problem hatte ich tatsächlich noch nie

  • Dav1310 Super, danke Dir für die Scores! Ich werde morgen, spätestens Freitag, das SMBIOS MacPro7,1 probieren und melde mich dann nochmal. Vielleicht verschwindet mit diesem dann auch der Boot-Fehler, wenn -no_compat_check nicht verwendet wird...

    Update:

    Hier die Ergebnisse der Performancetests via GeekBench 6.

    Windows 11 als Referenz:

    iMacPro1,1 NootRx:

    MacPro7,1 NootRx:

    iMacPro1,1 Whatevergreen:

    MacPro7,1 Whatevergreen:


    Und zusätzlich die Auswirkungen des AppleXcpmForceBoost-Kernel-Quirks

    iMacPro1,1 NootRx:

    MacPro7,1 NootRx:



    Ich muss wirklich sagen, dass ich das sehr interessant finde. Alleine was der ForceBoost bei MacPro7,1 rausholt. Beim iMacPro1,1 ist ForceBoost hingegen fast nicht bemerkbar. Jetzt ist ja aber mehr oder weniger der größere Knackpunkt, dass man ForceBoost nicht unbedingt nutzen sollte? Sonst sieht folgende Konfiguration ganz vielversprechend aus: iMacPro1,1 mit Whatevergreen. Ich werde ForceBoost auch noch einmal mit Whatevergreen anstatt NootRX testen - anscheinend hat das darauf doch Auswirkungen.


    Update:


    iMacPro1,1 Whatevergreen mit AppleXcpmForceBoost:

    MacPro7,1 Whatevergreen mit AppleXcpmForceBoost:

  • Flynn_LG

    Hat den Titel des Themas von „Boot-Probleme nach Upgrade von Ventura auf Sequoia“ zu „Sequoia-iMacPro1,1 - Boot-Arg „-no_compat_check“ nötig nach OCLP-Root-Patches, schlimm oder nicht?“ geändert.
  • Flynn_LG

    Ah krass, da haste ja gut gebenchmarked :)


    Ich muss wirklich sagen, dass ich das sehr interessant finde. Alleine was der ForceBoost bei MacPro7,1 rausholt. Beim iMacPro1,1 ist ForceBoost hingegen fast nicht bemerkbar. Jetzt ist ja aber mehr oder weniger der größere Knackpunkt, dass man ForceBoost nicht unbedingt nutzen sollte? Sonst sieht folgende Konfiguration ganz vielversprechend aus: iMacPro1,1 mit Whatevergreen. Ich werde ForceBoost auch noch einmal mit Whatevergreen anstatt NootRX testen - anscheinend hat das darauf doch Auswirkungen.

    Genau das habe ich gemeint. Das smbios vom iMacPro benötigt diesen Quirk nicht, um den Turbotakt zu erreichen. Wenn du AppleXcpmForceBoost mal google gibst, findest du einige Beiträge, die eben davon abraten. Ich habe mich darauf verlassen und habe eben versucht einen Weg zu finden, diesen Quirk zu umgehen. Und das war eben der Wechsel vom MacPro zum iMacPro.

    Das Opencore Manual sagt das dazu



    This patch writes 0xFF00 to MSR_IA32_PERF_CONTROL (0x199), effectively setting maximum multiplier for all the time.

    Note: While this may increase the performance, this patch is strongly discouraged on all systems but those explicitly dedicated to scientific or media calculations. Only certain Xeon models typically benefit from the patch.


    Performancetechnich waren beide grundsätzlich gleichauf, die Scores liegen ja alle schon nah bei einander, nur eben mit dem Unterschied, dass ich beim MacPro den Quirk aktivieren musste. Auch die Scores der GPU sind beim iMacPro leicht höher. Da bin ich dann beim iMacPro geblieben, weil ich auch ehrlich gesagt keine Lust mehr hatte, weiter zu suchen. Mein Hacki läuft so super stabil, ich kann alles damit machen, was ich machen möchte. Da habe ich irgendwann aufgegeben, das verstehen zu wollen :D