macOS 15 Sequoia Beta im Test

  • Z490 I5-10400 iGPU disabled in Bios RX6600 und SMBIOS MacPro7,1.

    Restrict Events und CPU Friend aktiv.

    Alles Release Candidate aktuell.

    Kein Problem.



    Nach üblichem SecureBootModel disabled und Secure Boot disabled installiert er jetzt brav und ich muss gleich wieder nach SecureBootModel set j160 die neuen OC Dateien Signieren im Bios und einen bless durchführen für 02% - Full Security Mode:


    boot in Recovery -> open Terminal:


    Code
    1. bless --folder "/Volumes/HD/System/Library/CoreServices" --bootefi --personalize

    Nach boot ins System -> open Terminal:

    Code
    1. nvram 94b73556-2197-4702-82a8-3e1337dafbfb:AppleSecureBootPolicy

    If the variable is found, it can be one of the following:

    • %02 - Full Security Mode
    • %01 - Medium Security Mode
    • %00 - No Security Mode

    Nach ein bisschen mdstore usw. sehr schön ruhig 0,23% CPU Last also anscheinend kein Problem mit

    Code
    1. PerfPowerServices
    • %02 - Full Security Mode

    auch wieder ohne Probleme...

    MacBook Air M2 16/1TB/10C - Win11 Pro 24H2 for Arm via UTM VM - Ubuntu Arm VM´s
    Hackintosh MSI Z490 I5-10400 32GB/4TB/RX6600 - Sequoia-15.2 - Win11Pro - Proxmox
     Macintosh 128K

  • Nutzt ihr bei den Rechnern den CPUFriend.kext oder irgendwelche anderen Dinge die das CPUPM beeinflussen?

    Nee, nur SSDT-PLUG. Werde ich später Testweise mal deaktivieren.

    Gruß, karacho



    Bitte keine Supportanfragen via PN. Eure fragen gehören ins Forum!

    Ich hab noch drei Patronen, eine für dich und zwei für mich...

  • Jein bei Insanely wird von einer Mischkonfiguration gesprochen sprich hier werkelt die iGPU und die dGPU und beide geben Bild aus ist also auch wieder ein "Spezialfall" (zumindest wenn der User DeeVeeDee gemeint ist) und Max.1974 nutzt in seinem Rechner eine AMD RX6900XT wenn ich richtig informiert bin :) Das "Problem" ist nicht vom Bootloader abhängig und tritt auf sobald das System die iGPU zur Bildausgabe verwendet egal ob mit Clover oder OC gestartet wurde.


    Den kernel_task kann man im übrigen getrost aus der Gleichung streichen denn, wie ich bereits erwähnt hatte, ist dessen Verhalten ein Schutzmechanismus von macOS um amoklaufende Prozesse auszubremsen und so ein mögliches überhitzen der CPU zu verhindern. Die "Last" die der kernel_task erzeugt ist eine Reaktion auf das Fehlverhalten von PerfPowerServices und dient dazu dem CPU belastenden Prozess CPU Zeit zu entziehen. Der kernel_task selbst erzeugt dabei keine nennenswerte Last blockiert aber den Prozessor für andere Prozesse und hilft so dabei die CPU Temperatur im Zaum zu halten. Bleibt PerfPowerServices dessen Aufgabe unter anderem das dynamische Regeln das CPU/GPU Takts in Reaktion auf die CPU/GPU Temperatur sowie Stromverbrauch und die verfügbare Stromversorgung (bei Laptops) ist. Wie ja inzwischen bekannt ist (danke an Majonéz von InsanelyMac fürs finden) hängt der Prozess in einem Loop beim lesen eines SMC Keys und da das Problem bisher nur bei Konfigurationen auftaucht die die iGPU nicht Headless verwenden liegt der Schluss nahe das es ein Key sein muss der irgendeinen Bezug zur iGPU hat (Temperatur, Takt, Stromverbrauch etc.)...

    Hallo zusammen, die Verzögerung bei der Beantwortung ist auf die Arbeit mit vielen Verpflichtungen zurückzuführen.


    Ich glaube, dass ich mehr als 5 Jahre lang eine „Feinabstimmung“ an meinem Lenovo E470 vorgenommen habe, das nur über eine Kaby Lake HD 620 verfügt, und mit Clover und Opencore, mit Rehabmans FakeSMC Kexts in Clover und Opencore, die normal aktualisiert werden, und mit YogaSMC, plus SSDTS für die Fans und plus den config.plist-Patches im ACPI-Tab habe ich es geschafft, die Fan-Manager (iStats-Menü, iStaticaPro...) zum Laufen zu bringen richtig. Ich kann sagen, dass im Fall von SSDTS und seinen Lüftern auf Laptops der Akku das Problem nicht löst, wenn es keinen korrekten Patch gibt, und ich sehe viele Leute, die ihr Glück allein auf die ECenabler-Kexts setzen. Müssen Sie sehen, ob Ihre SSDTS wirklich übereinstimmen, wie z. B. LPC? LPCB? Tastatur? Ich musste im Laufe der Jahre daran arbeiten und habe festgestellt, dass dies möglicherweise auf unzureichende oder unnötige Texte zurückzuführen ist. Ich verwende in keinem meiner Hacks mehr CpuFriend-Kexte. Überprüfen Sie Ihre Kexts und SSDTS und stellen Sie sicher, dass sie auf Ventura funktionieren. Das ist das Thermometer. Aber es dauert Wochen und Monate, bis es fertig ist.


    Auf meinen Desktops laufen alle SSDTS im gleichen Maße und die Lüfter funktionieren auf allen.


    Ich kompiliere alle meine Texte mit einem Programm, das unser Kanal entwickelt hat, und sie sind hervorragende Compiler. Sie müssen auch auf die Hardwarekompatibilität achten. Die Verwendung von iGpu, das eine Grafikbeschleunigung mit eGPU bietet, ist eine schlechte Wahl, wie ich bereits getestet habe, und es funktioniert nicht gut.

    3 Mal editiert, zuletzt von Max.1974 ()

  • Einmal editiert, zuletzt von schrup21 ()

  • Man kann den VirtualSMC auch als Nightly verwenden damit ist das Thema dann bereits jetzt schon erledigt. Habe den hier auf dem Eltiebook schon laufen und die Lage hat sich komplett normalisiert :) Super das solche Dinge so schnell und professionell von den Entwicklern erledigt werden.

  • Habe den hier auf dem Eltiebook schon laufen und die Lage hat sich komplett normalisiert

    Auch den ungepatchten RestrictEvents.kext wieder eingebunden? Viel Spaß euch noch auf dem Essener Stammtisch ;-)

    Gruß, karacho



    Bitte keine Supportanfragen via PN. Eure fragen gehören ins Forum!

    Ich hab noch drei Patronen, eine für dich und zwei für mich...

  • Jupp auch den wieder eingebunden :)

    Läuft alles wie es soll wieder.


  • Jo, hab auch gerade wieder umgewechselt, kann bestätigen alles ok wieder. Werde jetzt aber mal deinen Tipp testen, und ohne die SSDT-PLUG.aml starten. Dazu bin ich bisher noch nicht gekommen.

    Gruß, karacho



    Bitte keine Supportanfragen via PN. Eure fragen gehören ins Forum!

    Ich hab noch drei Patronen, eine für dich und zwei für mich...

  • Brauchst Du zumindest mit Blick auf die PerfPowerServices nicht machen denn der Fehler ist ja inzwischen eindeutig identifiziert und es ist bestätigt das das GPU/CPU PM nichts mit dem Bug zu tun hatte :)