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:

Nach boot ins System -> open Terminal:

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

• %02 - Full Security Mode

auch wieder ohne Probleme...

Zitat von griven

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.

Zitat von griven

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.

PerfPowerServices Thema: Problem sollte gelöst sein: ist gelöst:

https://github.com/acidanthera…0#issuecomment-2779430805

https://github.com/acidanthera…/actions/runs/14271379853

Am Montag gibt's wohl nen neuen VirtualSMC.kext welcher das Problem mit PerfPowerServices beseitigt. Dann können wir wieder den ungepatchten RestrictEvents.kext verwenden.

https://github.com/acidanthera/bugtracker/issues/2481

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.

Zitat von griven

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

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.

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

Im groben wurde die Art wie VirtualSMC auf fehlende Keys reagiert/antwortet geändert/berichtigt MacGrummel. Der alte Weg hat dazu geführt das im Fehlerfall sich ein Prozess der einen bestimmten Key aus dem SMC lesen wollte quasi totgelaufen hat weil eben die Rückmeldung das der gewünschte/angeforderte Key nicht vorhanden ist beim Prozess nicht so angekommen ist wie sie erwartet wurde. Im Falle von PerfPowerServices zum Beispiel hat das dazu geführt das der Prozess quasi in einer endlosen Schleife immer wieder neu gestartet wurde...

Und was ist das?

steht da doch

@Arkturus Nein Du hast es nicht verstanden, die Frage ist ob das ein falscher Alarm ist.

Kann mir nicht vorstellen das Acidanthera sich so einem Schnitzer leisten kann.

Jedoch ist es besser zu wissen ob da jemand etwas über Trojaner in VirtualSMC.kext weisst.

Bis Version 1.3.4 gibt es keine Probleme.

Mit der Version 1.3.4 hat Avast kein Problem. Deswegen ist es etwas seltsam.

Mit 1.3.5 erscheint diese Avast-Warnung ebenfalls.

Von wo hast Du die Datei geladen?

Ich lade meist von hier bzw. klicke dann auf die verlinkung auf die github Seite und lade direkt dort. Gut das Du die Meldung gepostet hast, dachte schon mein ClamXAV sieht Gespenster.

Ich muss später dann im log nachsehen was ClamXAV glaubte gefunden zu haben, als ich mit dem Kextupdater geladen hatte… (muss aber nat. nichts mit dem Kextupdater zu tun haben)

Nachtrag mein Logbuch von ClamXAV:

Dürfte wohl falscher Alarm sein...

Vgl. https://github.com/acidanthera/bugtracker/issues/2479