¿Hay alguna evidencia o documentación técnica que respalde la idea de que la Protección de la integridad del sistema puede causar un uso excesivo de la CPU por kernel_task en alguna situación?
Fondo
Sin batería. Todos los sistemas operativos de Apple en una unidad de disco duro externa, limitada (por la MacBookPro8,2) a USB 2.0.
Con Sierra, y con el lanzamiento de High Sierra, cuando no se iniciaba en modo seguro, casi siempre encontraba que kernel_task acaparaba la CPU.
Mi solución habitual era el modo seguro.
Después de considerar las respuestas a las siguientes preguntas:
- kernel_task consume 500% de CPU con alimentación de CA, a veces (2012-11-24)
- ¿Cómo deshabilitar el SpeedStep cuando se usa MacBook Pro sin batería? (2014-01-06)
- Kernel_task aumenta la CPU al 300% -500% (Yosemitte MBP 2011 sin batería) (2015-02-04)
- kernel_task cientos de% CPU pero la frecuencia de la CPU se está reduciendo (2015-04-01)
- Muy alto uso de la CPU kernel_task después de actualizar a Yosemite 10.10.4 (2015-07-04)
- Macbook Pro con un uso anormal de la CPU y una batería no reconocida. Cómo restablecer SMC alternativo (2015-09-02)
: mi objetivo era mover (dejar de lado) el siguiente archivo:
/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/MacBookPro8_2.plist
Requisito previo para la mudanza:
- deshabilitar la protección de integridad del sistema (SIP).
Después de usar csrutil(1) en el sistema operativo de recuperación 17A264c para deshabilitar el SIP, arranqué High Sierra en modo normal ...
... Me sorprendió gratamente encontrar que con .plist todavía en su lugar:
- en el modo normal sin SIP, la CPU ya no estaba saturada.
Apaga, comienza, no acaparando.
Comenzó 10.12, sin acaparamiento, actualizado a 10.12.5, reiniciado, sin acaparamiento.
2017-06-10 alrededor de las 16:50 el Mac se detuvo inesperadamente. Cuando se inició, a 10.12.5, noté que SIP se volvió a habilitar (no por mí). No acaparando.
Se inició el sistema operativo de recuperación 17A264c, SIP deshabilitado , se reinició a 10.12.5, sin acaparamiento ...