rMBP kernel_task spikes when connecting more than one external monitor

Question

When connecting a second external monitor kernel_task spikes to 600%+. This makes the computer unusable.

Before Yosemite, this worked fine with 3 monitors.

Here are the specifics:

• When I connect one monitor to either DP or HDMI things work fine.
• When I connect a second monitor with either DP or HDMI kernel_task spikes.
• When I disconnect either the DP or HDMI sometimes the kernel_task rapidly returns to normal levels.
• When I disconnect all monitors the kernel_task rapid returns to normal levels. (In Activity Monitor goto View > Update Frequency > Very Often and as soon as you disconnect the monitors, you will get lots of rapid updates to the UI).
• Occasionally when plugging in two monitors it works (DP or HDMI) but the 3rd causes an immediate spike. After this happens, all monitors must be removed for it to return to normal. Sometimes removing all but one will fix it.
• Sometimes when I plug all 3 in it takes 3 mins+ for it to occur.

What I have tried:

• Resetting NVRAM.
• Resetting SMC.
• Attempting the above scenario with power adapter plugged in and running on battery.
• Disabling "Automatic Graphics Switching" in Energy Saver.
• Using integrated graphics by using sudo pmset -c gpuswitch 0

NOTE: When trying some of these things sometimes it takes 1min to happen.

System config:

I am running a MacBook Pro Retina 2.7Ghz i7 (Macbook10,1 / Mid 2012) running Yosemite 10.10.1.

I have 3 external monitors (Dell 2415H) with 2 connected by Display Port and 1 with the HDMI.

---

I think the issue has to do with power management. Whenever my CPU hits 58 degrees it seems to occur. I just left my 3 monitors plugged in for 5+ mins and it didn't happen. But when I started searching using Chrome it immediately happened.

Looks like a good fix here: http://www.rdoxenham.com/?p=259

Answer 1

According to Rhys Oxenhams:

the kernel will keep looping some very simple tasks, e.g. getting the date, therefore ‘consuming’ (with the highest priority) the majority of the CPU in a bid to cool the system down.

The solution he mentions on his blog should work for earlier Macs. For Ivy-Bridge Macs and a little earlier Richard Schwarting has found the appropriate file to disable. Instructions are included below for convenience. I have tried many things, but this works.

1. Disable kext by renaming it

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

2. Clear kext cache (not sure if this is needed)

   sudo touch /System/Library/Extensions/
   

3. Restart

   sudo reboot
   

---

• After installing OSX updates you may need to repeat the above procedure if the updates have re-created the kext.

Update for (High) Sierra:

TL:TR

Rename IOPlatformPluginFamily.kext/ACPI_SMC_PlatformPlugin.kext/[MacModelIdentifier].plist

Step by step:

1. Start intro Recovery Mode (press CMD + R while startup)
2. Utility > Terminal csrutil disable (Disable system file protection)
3. Restart and rename /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/[MacModelIdentifier].plist (Mac > About > System Report > Model Identifier) to bugfix.plist (or something else)
4. Restart and check if kernal_task process is down below 10%
5. If successful restart again in Recovery Mode and enable system protaction again with csrutil enable

Tested and worked for me at 10.13.2 on Early 2011 MacbookPro.

Source with pictures (german) http://www.couchpiratin.de/mac-zu-langsam-kernel_task-cpu-fehler-beseitigen/

Answer 2

I spend multiple days before finding out the solution that worked for me. Just try using a different charging cable. Your Macbook is plenty capable of working with multiple monitors, but frayed/internally damaged cables can cause strangely cause the kernel to enter into an infinite loop.