rMBP kernel_task spikes al conectar más de un monitor externo [duplicado]

Al conectar un segundo monitor externo kernel_task spikes a 600% +. Esto hace que la computadora sea inutilizable.

Antes de Yosemite, esto funcionaba bien con 3 monitores.

Aquí están los detalles:

• Cuando conecto un monitor a DP o HDMI, las cosas funcionan bien.
• Cuando conecto un segundo monitor con picos de kernel_task DP o HDMI.
• Cuando desconecto el DP o HDMI a veces, kernel_task vuelve rápidamente a los niveles normales.
• Cuando desconecto todos los monitores, kernel_task vuelve rápidamente a los niveles normales. (En Activity Monitor, vaya View > Update Frequency > Very Ofteny tan pronto como desconecte los monitores, obtendrá muchas actualizaciones rápidas de la interfaz de usuario).
• Ocasionalmente, al enchufar dos monitores funciona (DP o HDMI), pero el tercero causa un pico inmediato. Después de que esto suceda, se deben quitar todos los monitores para que vuelva a la normalidad. A veces, eliminar todo menos uno lo arreglará.
• A veces, cuando conecto los 3, tarda 3 minutos + para que ocurra.

Lo que he intentado:

• Restableciendo NVRAM.
• Restableciendo SMC.
• Intentar el escenario anterior con el adaptador de corriente enchufado y funcionando con batería.
• Desactivar "Cambio de gráficos automático" en Energy Saver.
• Usar gráficos integrados usando sudo pmset -c gpuswitch 0

NOTA: Al intentar algunas de estas cosas, a veces toma 1 minuto para suceder.

Configuración del sistema:

Estoy ejecutando un MacBook Pro Retina 2.7Ghz i7 (Macbook10,1 / Mid 2012) con Yosemite 10.10.1.

Tengo 3 monitores externos (Dell 2415H) con 2 conectados por Display Port y 1 con HDMI.

Creo que el problema tiene que ver con la administración de energía. Cada vez que mi CPU alcanza los 58 grados, parece ocurrir. Acabo de dejar mis 3 monitores conectados durante más de 5 minutos y no sucedió. Pero cuando comencé a buscar usando Chrome, sucedió de inmediato.

Parece una buena solución aquí: http://www.rdoxenham.com/?p=259

De acuerdo con Rhys Oxenhams :

el kernel seguirá realizando algunas tareas muy simples, por ejemplo, obtener la fecha, por lo tanto, "consumir" (con la máxima prioridad) la mayoría de la CPU en un intento por enfriar el sistema.

La solución que menciona en su blog debería funcionar para Macs anteriores. Para Ivy-Bridge Macs y un poco antes, Richard Schwarting ha encontrado el archivo apropiado para deshabilitar . Las instrucciones se incluyen a continuación para mayor comodidad. He intentado muchas cosas, pero esto funciona.

1. Deshabilite kext renombrándolo

   cd /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/Plugins
   sudo mv X86PlatformShim.kext X86PlatformShim.kext.disabled
   

2. Borrar el caché de kext (no estoy seguro si es necesario)

   sudo touch /System/Library/Extensions/
   

3. Reiniciar

   sudo reboot
   

• Después de instalar las actualizaciones de OSX, es posible que deba repetir el procedimiento anterior si las actualizaciones han recreado el kext.

Actualización para Sierra (alta):

TL: TR

Cambie el nombre de IOPlatformPluginFamily.kext / ACPI_SMC_PlatformPlugin.kext / [MacModelIdentifier] .plist

Paso a paso:

1. Inicie el modo de recuperación de introducción (presione CMD + R durante el inicio)
2. Utilidad> Terminal csrutil disable(Deshabilitar la protección de archivos del sistema)
3. Reinicie y cambie el nombre /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/[MacModelIdentifier].plist(Mac> Acerca de> Informe del sistema> Identificador del modelo) a bugfix.plist(o algo más)
4. Reinicie y verifique si el kernal_taskproceso está por debajo del 10%
5. Si tiene éxito, reinicie nuevamente en el modo de recuperación y habilite la protección del sistema nuevamente con csrutil enable

Probado y funcionó para mí en 10.13.2 en MacbookPro de principios de 2011.

Fuente con imágenes (alemán) http://www.couchpiratin.de/mac-zu-langsam-kernel_task-cpu-fehler-beseitigen/