I think, I have found a reliable fix!!!
http://www.rdoxenham.com/?p=259
In my case I have a faulty battery that shows a temp of 129°f (always) so the system average temp is way off…
This is a part hardware: (My battery going from Health:80% 333 cycles, to Health:7% after a reboot, I think this is do to the battery thermometer getting stuck on 129°f and battery controller safety shutdown)
After moving MacBookPro8_2.plist, I have to say my machine feels like its running as fast as it was new out of the box! I think Apple might be using that Kernal_Task(0) for more then just heat control.. It would make a very interesting marketing tool if you catch my drift..
CAUTION: KNOW HOW HOT YOUR COMPUTER GETS BEFORE YOU DO THIS.
IF NO ONE HAS CLEANED OUT THE HEAT SINK FANS IN OVER A YEAR DO THAT BEFORE APPLYING THIS FIX.. Better safe then sorry..
From: Rhys Oxenhams' Tech Blog
“Fixing” kernel_task CPU Problems in MacOS 10.7/10.8
Posted on June 5, 2012
Update (Early 2013): When I wrote this guide it was focusing on Lion 10.7, many people have, of course, upgraded to 10.8 and have reported success using the same principles. However, the plist entries have not been added for newer models, e.g. the new MacBook Air or MacBook Pro (+retina). Therefore, if you follow the guide exactly you may run into problems such as your model identifier not being visible. After diagnosing this with others via email it would appear that the system uses another plist in the directory, therefore removing all of the plists has worked. I cannot comment further or prove this to be the case as I don’t have the available hardware. Let me know whether this works for you…..
I use a wide variety of operating systems at home, all services are provided by Linux, e.g. firewall, routing, file-storage and DLNA media. However, I like using a Mac too, I have a late-2009 MacBook Air which I use whilst traveling. Despite all of Lion’s flaws, I really like using it- full-screen apps, gestures and the new Mail.app is really impressive. The specification of this machine really isn’t anything special, the lack of expansion really leaves a lot to be desired but for what I do- it’s plenty. I will certainly be upgrading to the new Ivy Bridge MacBook Air when it comes out, perhaps then I’ll have more than 2GB memory and can run VM’s too(!).
The biggest problem I’ve been having with this machine on Lion (didn’t have it on Snow Leopard) is to do with kernel_task. Instead of splitting all of the underlying kernel operations into their own individual processes (and associated threads) they are all consumed by a single ‘task’ (more of a representation of the underpinnings of the microkernel architecture) that appears in the process list. What I’ve been noticing is that this ‘task’ sometimes goes out of control, consumes CPU resources with the utmost priority. For a long time I wasn’t sure what it was doing, it seemed to be kicking in when I was doing something that was relatively intensive (for a Mac anyway), e.g. YouTube.
A lot of people suggested that ‘rogue kexts’ (kernel drivers/modules) could be causing the problem, perhaps an incompatible module was being started by OS X that was installed when the system was running Snow Leopard. This seemed to make sense as a boot in safe-mode would cause no problems. Suffice to say, I created a Lion Install-USB and re-installed from scratch; guess what… same problem within hours! After a bit of digging around and investigating the kernel_task ‘process’ it was clear to see that it was looping through something continually. After further research I discovered that 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.
So, it’s all to do with temperature control- you ‘remove’ a large portion of the CPU share from other applications and carry out low-overhead tasks continually until the CPU temperature drops. This sounds like a great solution to cooling, but it’s very intrusive. It’s agressive nature drags the system to a halt in a lot of ways, despite the fact that the CPU in my MacBook Air rarely exceeds 70 degrees (centigrade). Considering the TJ Max of my little 2.13GHz Core2Duo is 85 degrees I’d rather kernel_task not take this invasive action.
Thankfully, this “feature” is built into a kext, in which each model identifier specifies how to control the temperature of the CPU via this invasive action. The simple fix is to remove the entry for your model identifier from this kext- if it “doesn’t know” what to do with your particular model, it won’t take any action. Now, here comes the disclaimer… by taking the same action as I will outline below, I take absolutely no responsibility for any damage or loss caused to you or your property, you do this of your own free will. You’re over-ruling functionality that was designed to prolong the life of your equipment, despite the fact that it’s invasive and very annoying it’s there for a reason. Anyway, on to the fun stuff…
Firstly, you’re going to need the model identifier of your pesky Mac:
$ system_profiler -detailLevel mini | grep "Model Identifier:" Model Identifier: MacBookAir2,1 |
The kext we need to modify is IOPlatformPluginFamily.kext, you can verify it is running by-
sh-3.2# kextstat | grep IOPlatformPluginFamily 67 3 0xffffff7f81229000 0x7000 0x7000 com.apple.driver.IOPlatformPluginFamily (5.1.0d17) <8 7 6 5 4 3> |
Within this kext will be another further kext- ACPI_SMC_PlatformPlugin.kext, in which each recent Macintosh model is listed with relevant instructions that the kernel uses to determine how and when to invoke the control. (Make sure you switch to root now)
sh-3.2# cd /System/Library/Extensions/IOPlatformPluginFamily.kext/ sh-3.2# cd Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/ sh-3.2# cd Contents/Resources/ sh-3.2# ls | wc -l 49 |
So, there’s 49 different profiles listed in this kext as of the writing of this. We simply need to move the ‘plist’ file for the model identifier we discovered earlier out of that directory, so in my case I need to move file ‘MacBookAir2_1.plist’ out of this directory (to somewhere safe), but replace my model identifier with your specific one.
sh-3.2# mv MacBookAir2_1.plist /Users/<your username>/ |
You can simply reboot now for the changes to take effect. We could have removed the entire kext but it’s much safer to remove the plist file for the specific model as (to be honest) I don’t know what the rest of that kernel module does. I’ve been using this ‘fix’ for a few days now and not noticed any problems at all- overall it’s much quicker and I don’t have to worry about it running out of steam. What I would recommend is that you be a bit more careful about the placement of your Mac, you don’t want to be covering the exhaust. The Mac should protect itself if it *does* reach max temperature but I would just be a little more careful.
Note: It’s likely that this kext will get updated in the future by Apple in their update packs and as a result will replace the file you deleted/moved therefore you may have to repeat this process in the future
Let me know how you get on.
