Hohe CPU Auslastung durch kernel task - mit Lösung lässt sich SIP nicht mehr aktivieren

[SpiderJoni]

Es ist ein ziemlich verbreitetes Phänomen, dass der kernel task in vielen Fällen gerne ma 400-500% CPU Leistung abzieht und das System nahezu lahmlegt. Mehrere Stellen im Internet vermuten hier ein Zusammenspiel mit der IOPlatformPluginFamily.kext, die mittels unzähliger Anleitungen unbenannt werden kann, um das Problem mit dem kernel task zu beheben.

Unter Big Sur sieht die Lösung etwas umfangreicher aus, weil durch das APFS nicht mehr das Live System gebootet wird, sondern jeweils nur noch ein Snapshot. Daher muss man zunächst FileVault deaktivieren, die SIP deaktivieren und den Authenticated-Root deaktivieren, um die Möglichkeit zu besitzen die IOPlatformPluginFamily.kext umzubenennen und von einem neu erstellen Snapshot zu booten.

Ich habe die Anleitung unter folgendem Link ausprobiert:

https://grafxflow.co.uk/blog/mac-os-x/delete-ioplatformpluginfamilykext-macos-big-sur

Das hat alles funktioniert.

Nur wenn ich am Ende den autenticated-root und den SIP wieder aktivieren möchte, bootet mein System nicht mehr. Erst dreht mein Lüfter komplett hoch, dann startet das System neu und zeigt die Fehlermeldung "Ihr Computer wurde aufgrund eines Problems neu gestartet. Drücken Sie zum fortfahren eine Taste oder warten Sie einige Sekunden."

Das System bleibt dann in einer Boot Schleife hängen und kommt nicht weiter.

Erst wenn ich wieder im Recovery Modus startet und den SIP und Authenticated-Root deaktiviere, bootet der wieder normal. Aber dadurch habe ich ein System ohne System Integration Protection. Das ist kacke.

Kann mir hier jemand helfen, oder sollte ich einfach MacOS drüber installieren, damit meine Schandtaten hinsichtlich der Umbenennung der IOPlatformPluginFamily.kext wieder ausgemerzt werden???

 

[lisanet]

Kann mir hier jemand helfen, oder sollte ich einfach MacOS drüber installieren, damit meine Schandtaten hinsichtlich der Umbenennung der IOPlatformPluginFamily.kext wieder ausgemerzt werden???

... drüber installieren ist die bessere Wahl.

Ab Big Sur ist das System kryptografisch signiert. Durch deine Änderungen ist dieses Siegel nicht mehr gültig. Du kriegst das auch nicht mehr hin, außer durch ein Neuinstallieren.

BTW, von deinem Problem habe ich bislang nichts mitbekommen. Es scheint für mich daher kein grundsätzliches Thema zu sein, sondern (wie halt so oft) durch andere Aspekte getriggert zu werden und nicht alleine durch das System selbst.

 

[SpiderJoni]

Das Problem ist in der Tat weit verbreitet und der Frust der User entsprechend hoch. Musst nur mal "kernel bug macOS" bei Google eintippen. Da findest Du Tausende Seiten und Foreneinträge, die das thematisieren.

Ich habe jetzt gerade mal MacOS drüber installiert und dabei wurde aber leider nicht die SIP und der Authenticated-Root aktiviert. Aber die Kernel Extension war wieder da - die ich umbenannt habe. Somit konnte ich im Recovery Modus wieder die SIP einschalten und den Authenticated-Root aktivieren. File Vault ließ sich danach auch wieder aktivieren. Also erstmal alles wieder wie vorher.

Der Kernel Bug lässt das System aber regelmäßig minutenlang einfrieren, weil er scheinbar die CPU-Leistung drosseln muss, um eine Überhitzung zu vermeiden, obwohl sich der Rechner im Leerlauf befindet. Ist halt ein Bug...

Unzufriedenstellend...

 

[lisanet]

Der Kernel Bug lässt das System aber regelmäßig minutenlang einfrieren, weil er scheinbar die CPU-Leistung drosseln muss, um eine Überhitzung zu vermeiden, obwohl sich der Rechner im Leerlauf befindet. Ist halt ein Bug...

Ich hatte das bisher nicht. Weder unter meinen Intels die auch mit Catalina / Big Sur liefen, noch jetzt mit dem M1. So weit verbreitet kann es also nicht sein.

Und ich mach auf meinen Rechner schon durchaus anspruchsvolle Dinge, (Software-Entwicklung, Video, Foto) bin aber auch eine, die sich gut im System auskennt und nicht jeden Mist sofort installiert, der daher gelaufen kommt. Und daher traue ich mir schon zu, etwas unterscheiden zu können, ob es ein genereller bug im System ist, oder aber um einen, der nur bei bestimmten Szenarien auftritt.

Und meine Macs sind nicht in der von dir beschriebenen Weise "eingefroren".

 

[dg2rbf]

Hi,
lisanet, komm mal runter, du musst nicht immer von Dir auf Andere schliessen!.
Franz

 

[lisanet]

Hi,
lisanet, komm mal runter, du musst nicht immer von Dir auf Andere schliessen!.
Franz

ich bin ja überhaupt nicht aufgeregt, da brauche ich nicht runter kommen.

ich mag es nur nicht, wenn erst mal behauptet wird, dass das OS einen grundsätzlich Fehler hätte, wenn dieser angebliche Fehler halt nur in speziellen Szenarien auftritt.

Und das was ich hier zu den besagten kext und kernel_task im Netz gefunden habe, waren Szenarien und mögliche Ursachen wie: ausgebauter Akku, defekte Lüfter, nicht korrekt funktionierende Temp-Sensoren durch Umbauten etc. Also eher Dinge, die nicht im OS selbst begründet sind. Und das passt dann auch wiederum zu meiner ganz konkreten Erfahrung, nämlich das bei meinen Rechner, dieses Einfrieren / 400% CPU durch kernel_task bisher nicht vorgekommen ist.

 

[SpiderJoni]

Wenn man etwas tiefer bei Google recherchiert kommt dieser kernel bug aber durchaus auch (nicht selten) im regulären Betrieb hoch. Ich habe zum Beispiel auch keine exotische Software laufen und bin hier auch eher bedacht darauf, was ich installiere und was nicht. Der kernel bug scheint offenbar nicht ausschließlich auf fehlerhafter Hardware gegründet zu sein (durch unsachgemäße Umbauten etc. - was ich ja nicht gemacht habe), sondern auch durch fehlerhafte Temperatursensoren, die zur Fehlinterpretation des Überhitzungsgrades führen, weswegen der kernel dann die Leistung der CPU drosselt, damit keine Überhitzung droht. Wenn einem - wie mir - so ein Fehler im System auffällt, obwohl keine offensichtlichen Szenarien eintreffen, forscht man etwas tiefer und kommt dann auch auf Betroffene - und das sind nicht wenige - die aus dem heiteren Himmel diesen Bug als störend im alltäglichen Betrieb empfinden.

Manche scheinen nicht betroffen zu sein, wie Du, Lisanet, manch andere aber schon. Alle über einen Kamm zu scheren ist aber selten zielführend...

 

[dg2rbf]

 

[SpiderJoni]

"fehlerhafte Termperatursensoren" klingt natürlich auch erstmal nach Hardwaredefekt, was ich so aber nicht meinte. Eher dass die Temperatursensoren die Temperaturen falsch messen oder falsche Schlussfolgerungen aus ihren Messungen ziehen.

 

[lisanet]

"fehlerhafte Termperatursensoren" klingt natürlich auch erstmal nach Hardwaredefekt, was ich so aber nicht meinte. Eher dass die Temperatursensoren die Temperaturen falsch messen oder falsche Schlussfolgerungen aus ihren Messungen ziehen.

na dann, wenn du sagst, dass wenn Sensoren falsch messen, dass ein Software-Fehler sei...

... dann müssten ja in all meinen Rechner andere Sensoren verbaut sein, und zwar solche, die von der Software korrekt ausgelesen werden. Kann natürlich sein, da hast du vollkommen recht. Denn wenn es ein Softwarefehler ist, dann ist er ja auch auf meinen System vorhanden und wir nur nicht getriggert. ODer siehst du das anders?

In dem Fall wäre es dann schon mal interessant welche Sensoren (sprich welcher Mac) falsch ausgelesen werden. Nicht sein kann es ein iMac 27" Latr 2015, ein MBA 2019 und ein Mini M1. Was hast du für ein Notebook?

Wie dem auch sei, du hast ja deine Lösung für einen Software-Fehler im System gefunden.

 

[SSC_Jarod]

Greife diesen alten Thread mal wieder auf. Mein MacBook Pro 16" 2019 hat es seit 2 Tagen jetzt auch erwischt. kernel_task nach 5-10 Min. jenseits der 1.000er Grenze. Alles an Tipps und Tricks ausprobiert und nichts hat geholfen, bis ich auf die Idee kam, als er mal wieder zwischen 800-1.200% pendelte, die USB-C Docking Station rauszuziehen... und siehe da, nach ca. 20 Sekunden war der kernel_task wieder bei 1-8% angelangt. Jetzt drängt sich mir nur die Frage auf warum?! Kann das Ding kaputt sein, obwohl alles normal (LAN, Monitor, Drucker, USB) über das Ding läuft auch wenn kernel_task >700 hochläuft... Seltsam... Hab jetzt mal ne neue DS bestellt und teste.

 

[lisanet]

Danke für deine Infos.

Das bestätigt meine Erfahrung, dass dieser Effekt oft durch Hardware getriggert wird. Ich gehe mal davon aus, dass die betreffende Dockingstation im Betrieb recht warm wird, oder?

 

[SSC_Jarod]

Danke für deine Infos.

Das bestätigt meine Erfahrung, dass dieser Effekt oft durch Hardware getriggert wird. Ich gehe mal davon aus, dass die betreffende Dockingstation im Betrieb recht warm wird, oder?

Ja das stimmt. Sie wird schon sehr sehr warm. K.A. woran es liegt, da es auch keine 08/15 billig DS war. Hab in einigen US Foren gelesen, dass es wohl bei den meisten am externen Monitor hängen soll. Auch wenn nur 1 angeschlossen ist. Scheint ein bekanntes Problem zu sein, auch bei Apple. Heute soll die neue kommen und da hoffe ich mal, dass dann wieder alles i.O. ist.

 

[lisanet]

Ja das stimmt. Sie wird schon sehr sehr warm. K.A. woran es liegt, da es auch keine 08/15 billig DS war. Hab in einigen US Foren gelesen, dass es wohl bei den meisten am externen Monitor hängen soll. Auch wenn nur 1 angeschlossen ist. Scheint ein bekanntes Problem zu sein, auch bei Apple. Heute soll die neue kommen und da hoffe ich mal, dass dann wieder alles i.O. ist.

soweit ich das weiß liegt das daran, dass diese Docks das Monitorsignal und den Rest (USB, LAN) ja intern nicht einfach durchschleifen, sondern da musss ja das eingehende TB-Signal ja "aufgetrennt" und an die jeweiligen Ports weiter gereicht werden. Und dazu braucht es halt CPU, die dann auch warm wird.

 

[SSC_Jarod]

soweit ich das weiß liegt das daran, dass diese Docks das Monitorsignal und den Rest (USB, LAN) ja intern nicht einfach durchschleifen, sondern da musss ja das eingehende TB-Signal ja "aufgetrennt" und an die jeweiligen Ports weiter gereicht werden. Und dazu braucht es halt CPU, die dann auch warm wird.

Sie neue DC ist jetzt angekommen und läuft seit 1 Stunde ohne kernel_task Probleme. Hoffe das bleibt auch so. Denn dann kommt dort noch n SSD 2 TB Riegel rein und ich kann meine alte SSD in den Ruhestand schicken und hab nur noch 1 Geräte aufm Schreibtisch, das alles regelt.

 

[SSC_Jarod]

Update: alle beim alten. Leider! Task geht nach ca. 30-45 Minuten wieder ins unendliche. Egal welchen Monitor mit welchem Anschluss (HDMI, ,VGA) dranhänge. Auch alle Tips und Tricks mit SMC und NVRAM löschen helfen hier auch nix. hab jetzt HDMI abgeklemmt und nutze DS nur für Drucker, LAN und Festplatte. Bin mit meinem Latein am Ende.

 

[lisanet]

Dein Dock ist ja nur ein USB-C Dock. Ich dachte, das wäre ein Thunderbolt-Dock. Die Beschreibung ist auch sehr dürftig gehalten und 1 Rezession bestätigt das. Da ist noch nicht mal klar, was die Schnittstelle Mac - Dock kann. Wegen der Unterstützung von 2k@60Hz vermute ich mal das das USB 3.2 Gen 2, sprich max 10 GBits sind.

Da muss dann der gesamte Datenverkehr durch 1 USB-Port durchgeleitet werden. Und was du so alles an dem Dock dran hast ist das ne ganze Menge. Sprich, abgesehen davon, dass diese 10 GBits sich nun auf Monitor (der immer Vorang genießt), LAN und Festplatte aufteilen müssen, was spätestens entweder das Netzwerk oder die Platte verlangsamen, muss der Mac über den 1 Port ne ganze Menge arbeiten. Das dabei der Treiber und damit kernel_task eine hohe Last kriegt ist für mich durchaus nachvollziehbar.

Ich würde sagen, auch wenns hart klingt: an der falschen Stelle gespart und falsche Dock für deinen Einsatzzweck gekauft. Ein Thunderbolt-Dock wäre da wohl sinnvoller gewesen. Kostet halt mehr. Abgesehen davon, verstehe ich eh nicht so recht, wieso man sich einen mobilen Rechner kauft und den dann mit Monitor und kabelgebundener Peripherie betreibt.

 

[SSC_Jarod]

Dein Dock ist ja nur ein USB-C Dock. Ich dachte, das wäre ein Thunderbolt-Dock. Die Beschreibung ist auch sehr dürftig gehalten und 1 Rezession bestätigt das. Da ist noch nicht mal klar, was die Schnittstelle Mac - Dock kann. Wegen der Unterstützung von 2k@60Hz vermute ich mal das das USB 3.2 Gen 2, sprich max 10 GBits sind.

Da muss dann der gesamte Datenverkehr durch 1 USB-Port durchgeleitet werden. Und was du so alles an dem Dock dran hast ist das ne ganze Menge. Sprich, abgesehen davon, dass diese 10 GBits sich nun auf Monitor (der immer Vorang genießt), LAN und Festplatte aufteilen müssen, was spätestens entweder das Netzwerk oder die Platte verlangsamen, muss der Mac über den 1 Port ne ganze Menge arbeiten. Das dabei der Treiber und damit kernel_task eine hohe Last kriegt ist für mich durchaus nachvollziehbar.

Ich würde sagen, auch wenns hart klingt: an der falschen Stelle gespart und falsche Dock für deinen Einsatzzweck gekauft. Ein Thunderbolt-Dock wäre da wohl sinnvoller gewesen. Kostet halt mehr.

Da ich aber nur 4 USB-C am McBook pro 2019 hab, passt da leider kein Thunder dran. Es hat ja auch bisher, ohne das ich etwas geändert hab, funktioniert. Daher verstehe ich das mit dem Kernel_task erst recht nicht. Es wurde nix an der Konfiguration geändert. Und selbst wenn ich mir nen usb-c->thunderbolt adapter hole, geht ja alles trotzdem über den einen usb-c. Vor allem weder mein privates McBookAir noch mein 2018er Mac mini, haben mit ähnlichen DockingStations Probleme. Egal ob mit ext. Monitor oder nicht.

Abgesehen davon, verstehe ich eh nicht so recht, wieso man sich einen mobilen Rechner kauft und den dann mit Monitor und kabelgebundener Peripherie betreibt.

Das liegt mit meiner Arbeit zusammen. Ich arbeite zu 60 % im Büro und 40% mobil. Da brauch ich genau den Laptop wg. Daten, Zugang und unserer Software. Da nutzen zwei Rechner nichts. Und es gibt sehr viele User, die auswärts mobil arbeiten und @home ne Docking Station haben. Simple as that

 

[lisanet]

Vor allem weder mein privates McBookAir noch mein 2018er Mac mini, haben mit ähnlichen DockingStations Probleme. Egal ob mit ext. Monitor oder nicht.

Wenn auf allen 3 Geräten die gleiche Peripherie angeschlossen ist und identich genutzt wird und auf den Geräten das gleiche System und die gleiche Software ist, dann deutet das eher auf ein Hardware-Problem hin.

Und wenn das Notebook keine Thunderbolt hat, dann kannst du es klar nicht nutzen. Ich habe dir ja nur versucht zu erklären, dass ein USB-Dock mit dieser Anzahl an zu versorgenden Geräten halt nicht so toll ist, da alles durch diesen einen Port muss und sich die Bandbreite teilen muss, was dann eben eng und Last sowohl am Dock als auch am MacBook verursacht.

Und auch wenn es sehr viel User machen, sich einen mobilen Rechner kaufen um dann mit Hubs und Docks den zum Desktop zu machen, es ist einfach ein grenzwertiger Einsatzbereich, wenn man da dann viele Geräte dran hängt. Les mal hier die Threads darüber. Neben den bei Desktops üblichen Problemen kommt halt hier noch ein weiteres Teil in der möglichen Fehlerkette hinzu.

 

[Johanna K]

Da ich aber nur 4 USB-C am McBook pro 2019 hab, passt da leider kein Thunder dran.

Die 4 Ports am MacBook Pro sind Thunderbolt-Ports, in dem Falle mit TB3. Da passt sowohl Peripherie für USB als auch für TB dran. Besorge dir ein Thunderbolt-Dock mit TB 3 und USB-C-Stecker.

Dein Dock ist nur USB-C und damit suboptimal. Auch Docking-Stationen für TB1 und TB2, die sich über Adapter anschließen ließen, sind weniger zu empfehlen.