macOS 15 Sequoia Beta im Test

Coole Sache das schrup21 danke für den Link.

Update RC2 war hier problemlos, 700MB mit OCLP Patche revidiert (AirportBrcmFixup und BluetoolFixup ist dank BCM64360NG nicht aktiv):

MacGrummel Vor einiger Zeit habe ich es zu einem Laden gebracht, der sich auf Lüfter, die Reinigung des Prozessors und den Austausch der Wärmeleitpaste spezialisiert hat. Sowohl mein Notebook als auch einer meiner Hacks aus der Coffe Lake-Reihe mit einer RX 64 Vega-Karte mit Wasserkühler senkten die Temperatur nicht und die Lüfter waren sehr laut. Es ist sehr gut geworden. Es wäre interessant, nach der Reinigung und dem Wechsel der Wärmeleitpaste einen eigenen Test durchzuführen.

42ºC

So richtig rund läuft die neue Beta aufm dem M4 nicht.

Scheint ein Memory leak zu sein.

Der sich nach einer Weile von selber wieder geleert hat.

Max.1974 einige von uns haben seit der 1. Beta 15.4 ein Problem mit PerfPowerService, iGPU Maschinen scheinen betroffen zu sein - siehe auch hier:

https://www.insanelymac.com/fo…quoia-154-high-cpu-usage/

Hp 250 G8 läuft jetzt mit Open Core 1.04.

OpCore-Simplify hat mir das meiste abgenommen. Mit OCAT den Rest erledigt.

Hat halt ein paar Tage gedauert. Ein großes danke geht an alle die daran gearbeitet haben Neues Projekt: HP-250 G8 (i5-1035G1) - Touchpad will noch nicht und auch ein großes Danke geht an greecedrummer für die Bereitstellung der EFI.

Noch ne neue Version für die Release (nach Beta-Updates auf Aus):

OCLP 2.3.0 ebenfalls raus:

Update wie gewohnt problemlos, PerfPowerServices, kernel_task Problem leider immer noch vorhanden (also ohne die gepatchte RestrictEvents.kext).

Naja das Problem wird auch bleiben zumindest solange nicht gelöst ist welche SMC Keys die PerfPowerServices da ständig suchen und nicht finden...

Der KernelTask ist ein Nebeneffekt von der anderen Geschichte. Der KernelTask wird unter macOS dazu genutzt CPU Intensive Prozesse auszubremsen und so ein Überhitzen der CPU zu vermeiden. Der KernelTask läuft auf hoher Priorität und "klaut" somit CPU Intensiven Prozessen CPU Zeit. Der Task selber erzeugt keine echte Last auf der CPU sondern "blockiert" diese nur für andere Prozesse. vgl. Apple Support: https://support.apple.com/de-de/102172

Im Großen und Ganzen denke ich ist der Weg über RestictEvents aber vielleicht auch gar nicht so verkehrt denn PerfPowerServices bzw. dessen Funktion sind schon sehr Mac spezifisch am Hackintosh fährt man ohne den aktiven Prozess daher möglicherweise sogar besser zumindest wenn das stimmt was auf der chinesischen Website dazu steht die Du bei insanelymac referenziert hast schrup21

An meinem Hackintosh kann ich keine Probleme mit KernelTask oder PerfPowerService beobachten. Es steht ja die These im Raum, dass es nur Geräte betrifft, die die iGPU als bildgebende GPU nutzen. Das ist auch nur ein OC-Problem, Cover scheint das nicht zu haben, wenn ich Max.1974 richtig verstehe.

Zitat von Nordel

die die iGPU als bildgebende GPU nutzen

scheint nicht ganz der Fall zu sein, bei Insanely berichtet jemand vom gleichen Verhalten mit dGPU (eingesetzt in eigentlich nativ iGPU Mac Mini SMBios).

https://www.insanelymac.com/fo…equoia-154-high-cpu-usage

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.)...

OCLP v2.3.1

Changelog und Download hier:

https://github.com/dortania/OpenCore-Legacy-Patcher/releases

Nachtrag zur PerfPowerServices Thematik: Das Problem betrifft "nur" Hackintosh Systeme echte Äpfel scheinen nicht betroffen zu sein Ich habe eben mein 2015 MBP (13 Zoll, Broadwell Grafik) mit dem OCLP 2.3.1 auf Sequoia 15.4 gehoben und hier verhält sich der Prozess komplett unauffällig. Damit ist im übrigen auch die Bootloader Frage abschließend geklärt da ja auch dieses System über OC startet

Also bei mir spinnt der PerfPowerService und der kernel_task nach dem Update auf 15.4 trotzdem, obwohl meine iGPU im Bios abgeschaltet ist und ich nur die Vega nutze. Der Terminalbefehl von schrup21 hat hier für Abhilfe gesorgt.

Nutzt ihr bei den Rechnern den CPUFriend.kext oder irgendwelche anderen Dinge die das CPUPM beeinflussen? Neben der iGPU Geschichte wird auch davon berichtet das PerfPowerServices gelegentlich auch damit kollidieren. Zudem könnt ihr auch testweise mal die SSDT-Plug deaktivieren sofern vorhanden da diese zumindest theoretisch ab macOS 12.3 nicht mehr notwendig ist (bisher hat es nicht geschadet wenn sie da war aber das mag sich geändert haben)...

Ich hab meine iGPU deaktiviert, SSDT Plug und CPUfriend am laufen und bisher ist das Problem bei mir noch nicht aufgetreten.