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

  • beside of CPU what other task goes up in activity?
    – Ruskes
    Commented Jan 5, 2015 at 7:52
  • Nothing, just kernel_task.
    – vaughan
    Commented Jan 5, 2015 at 10:48
  • @bmike Why is this question marked as duplicate for a question that was asked later, and has a less complete accepted answer?
    – vaughan
    Commented May 19, 2019 at 16:40
  • Does this answer your question? How to find cause of high kernel_task cpu usage? Commented Aug 15, 2022 at 15:47

2 Answers 2


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:


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/

  • 6
    Even with sudo getting mv: rename X86PlatformShim.kext to X86PlatformShim.kext.disabled: Operation not permitted when trying to move...
    – Shwaydogg
    Commented May 28, 2016 at 16:16
  • 5
    @Shwaydogg You probably need to disable OSX SIP. See osxdaily.com/2015/10/05/…
    – vaughan
    Commented Jun 11, 2016 at 2:04
  • 6
    This is the correct answer. Why this question is marked as duplicate and says it already has an answer is crazy to me. Thanks so much for looking into the help. Commented Jun 21, 2016 at 23:02
  • 5
    Update: I am running Sierra and I'm having issues with the kernal_task again. This solution is not enough anymore.
    – bheussler
    Commented Oct 21, 2016 at 22:36
  • 8
    My model identifier says MacBookPro11,3 but there is no 11,3 plist file. Which one do i need to rename?
    – JohnRW
    Commented Apr 8, 2018 at 16:39

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .