10.9.1 kernel_task hogging one CPU core 100%

GoSUV · Jan 12, 2014

Don't know when this started, but it must have happened after the update to 10.9.1, that my MBP's fan was roaring one day even just doing light work. Upon checking the Activity Monitor, this "kernel_task" process was hogging one CPU core to 100% and my computer was like having one brain chopped off.

Upon Googling for this odd behavior, and found a number of such complaints from 10.9.1 users, mostly portables rather than iMac's and Mini's, this seems to be very common to Mavericks. I tried the various tips and tricks, such as unplugging a pair of headphones, shutting down and rebooting, resetting the PMC, all to no avail.

I wouldn't have minded if my Mac is a recent rMBP with 4 cores and loads of RAM, and if a shutdown and reboot took care of it, but even after numerous attempts to shut down, rebooting, and running no other applications, to turning off wifi and access to internet, this "kernel_task" process still continues to hog a CPU core to 100%, seemingly even prior to me logging on (it's doing it from the Apple grey screen), I can't see what I need to do to get rid of it. It has a PID of 0 and belongs to the root user, so I can't kill it from the Terminal window.

My MBP is a circa 2007 C2D 2.2GHz with only 4GB of RAM, so I can ill-afford to use a CPU core. The computer is still barely usable, but not much more.

HELP!

ufkdo · Jan 13, 2014

The same thing happened to me once. I solved it by uninstalling 3rd party kernel extensions. So far so good.

GoSUV · Jan 14, 2014

I booted into Safe Mode and the issue is still happening. Safe mode is supposed to only load the bare minimum extensions, is it not? It looks like the CPU hogging is beginning to happen before the Mac is even booted, at the grey Apple screen stage, as the fan will start roaring as soon as that screen.

I tried the various fixes and workarounds posted around Apple's Discussion boards and the internet, including removing the plist file specific to my MBP model, plugging/unplugging headphone with the lid open/closed, rebooting, resetting PRAM/SMC, turning on/off the mic, and the above booting into Safe mode, all to no avail.

This is a circa 2007 MBP with a Core2duo processor and I can ill-afford to lose a CPU core just to that stupid kernel_task process. The computer now barely runs.

ufkdo · Jan 15, 2014

GoSUV said:
I booted into Safe Mode and the issue is still happening. Safe mode is supposed to only load the bare minimum extensions, is it not? It looks like the CPU hogging is beginning to happen before the Mac is even booted, at the grey Apple screen stage, as the fan will start roaring as soon as that screen.

I tried the various fixes and workarounds posted around Apple's Discussion boards and the internet, including removing the plist file specific to my MBP model, plugging/unplugging headphone with the lid open/closed, rebooting, resetting PRAM/SMC, turning on/off the mic, and the above booting into Safe mode, all to no avail.

This is a circa 2007 MBP with a Core2duo processor and I can ill-afford to lose a CPU core just to that stupid kernel_task process. The computer now barely runs.

Do you mind entering the following command in Terminal and sharing the results here?

Code:

kextstat -kl | awk '!/com\.apple/{printf "%s %s\n", $6, $7}' | open -ef

The command will simply check for non-Apple kernel extensions and open the results in textedit.

GoSUV · Jan 15, 2014

ufkdo said:
Do you mind entering the following command in Terminal and sharing the results here?

Code:

kextstat -kl | awk '!/com\.apple/{printf "%s %s\n", $6, $7}' | open -ef

The command will simply check for non-Apple kernel extensions and open the results in textedit.

Thanks. I copied and pasted the above command in Terminal, and the resulting TestEdit file is blank.

ufkdo · Jan 15, 2014

GoSUV said:
Thanks. I copied and pasted the above command in Terminal, and the resulting TestEdit file is blank.

Oh, then you don't have any 3rd party kernel extensions and I frankly don't know what else may cause the issue.

ElectricSheep · Jan 15, 2014

You might try using a script like hotkernel which leverages d-trace to see what is spending the most time executing on the CPU. Copy of the contents of the linked page to a text file, chmod a+x the file in a terminal to make it executable, then execute it with sudo while kernel_task is burning up a core.

That should tell you exactly what kernel_task is doing that is taking up so many cycles.

ouimetnick · Jan 16, 2014

Simply back up all your important data, wipe the hard drive, and reinstall OSX Mavericks.

GoSUV · Jan 17, 2014

I will try the hotkernel script later on, but at this point I'm not convinced wiping the hard drive and doing a fresh install will completely resolve it, due to many reports saying this action making no difference at all. And this is something I would be reluctant to try for fear of making even more things stop working after it.

After letting the computer sleep with the lid closed for more than 24 hours, I can now even hear the fan roar as I believe the computer isn't sleeping at all, the stupid kernel_task process must still be running even with the lid closed. Now this is strange. The only action I can stop it running is by shutting the computer completely off. As soon as it starts up, at the grey screen and before logging in, the fan will roar again and I know it would be running.

This continues to happen even after resetting PRAM/SMC and as written before, I have no 3rd party kernel extensions.

ElectricSheep · Jan 17, 2014

GoSUV said:
I will try the hotkernel script later on, but at this point I'm not convinced wiping the hard drive and doing a fresh install will completely resolve it, due to many reports saying this action making no difference at all. And this is something I would be reluctant to try for fear of making even more things stop working after it.

After letting the computer sleep with the lid closed for more than 24 hours, I can now even hear the fan roar as I believe the computer isn't sleeping at all, the stupid kernel_task process must still be running even with the lid closed. Now this is strange. The only action I can stop it running is by shutting the computer completely off. As soon as it starts up, at the grey screen and before logging in, the fan will roar again and I know it would be running.

This continues to happen even after resetting PRAM/SMC and as written before, I have no 3rd party kernel extensions.

Its possible that the kernel is doing some kind of software throttling. I have read that the mach kernel in MacOS X will, if all other thermal-management techniques fail, schedule itself to do essentially nothing in a last ditch effort to prevent the machine from catastrophically overheating. The hotkernel script might shed some light on this.

If that is the case, then for whatever reason the machine isn't able to manage it own temperature: hardware failure, kernel cannot talk to the system management circuitry, who knows.

fluxforge · Jan 18, 2014

GoSUV said:
Don't know when this started, but it must have happened after the update to 10.9.1

Yeah, that's when it started for me, too. Constantly one core 100% devoted to kernel_task. This decimates my MacBook Air's (latest 2013 model) battery runtime which sucks as the long battery time was the primary reason I got the MBA :/

Needless to say I couldn't find a way to trigger this bug - nor to stop it. Sometimes quitting Safari would help for a few minutes. And yes, I reinstalled OS X too. No help.

I hope this problem will get fixed with 10.9.2 ...

ElectricSheep · Jan 18, 2014

Something else that can be done to investigate: In the Terminal, run the following command:

Code:

 sudo sysdiagnose -f ~/Desktop/

It will produce a gzipped archive on your Desktop. Double-click to open and look for the following file:

Code:

powermetrics.txt

There is a section in this file called "Session Interrupt distribution". Copy and paste that section here.

GoSUV · Jan 19, 2014

The following is the partial output from the hotkernel script, assuming where towards the end of the file are the processes/procedures which get executed the most often:

AirPortAtheros40`ieee80211_mlme_is_connected 3 0.8%
NVDAResmanTesla`fbInsertSortDescendingHeadBw 4 1.0%
GeForceTesla`IONVGraphicsClientTesla::addTextureToStream(nvTextureBuffer*) 4 1.0%
NVDAResmanTesla`hdmiCalculateN 4 1.0%
AirPortAtheros40`ieee80211_input 4 1.0%
AirPortAtheros40`ath_rx_tasklet 5 1.3%
NVDAResmanTesla`odbGetClass 6 1.5%
AppleMatch`addNodeToList 6 1.5%
NVDAResmanTesla`nvLogBase2 7 1.8%
pthread`workqueue_run_nextreq 7 1.8%
NVDAResmanTesla`gpuExecRegOps 8 2.1%
AppleMatch`matchExec 12 3.1%
corecrypto`ccsha1_vng_intel_compress_SSE3 132 33.9%
MacBookPro: Desktop

The following are the captures from the "powermetrics.txt" file's Session Interrupt distribution:

**** Session Interrupt distribution ****

CPU 0:
Vector 0x42(HPET): 72.45 interrupts/sec
Vector 0x46(SMC): 0.00 interrupts/sec
Vector 0x49(MacBookPro3,1): 9.18 interrupts/sec
Vector 0x50(PEGP/GFX0/UHC5/pci-bridge/RP05/ARPT/UHC1): 31.71 interrupts/sec
Vector 0x52(RP03/UHC2/SATA): 190.07 interrupts/sec
Vector 0x53(FRWR): 0.04 interrupts/sec
Vector 0x54(UHC4/HDEF/EHC1/SBUS): 0.42 interrupts/sec
Vector 0x55(EHC2/UHC3/PATA/PRID/CHN1): 60.29 interrupts/sec
Vector 0x90(HDEF): 6.16 interrupts/sec
Vector 0x91(GIGE): 0.03 interrupts/sec
Vector 0x94(GFX0): 17.60 interrupts/sec
Vector 0xdd(TMR): 369.54 interrupts/sec
Vector 0xde(IPI): 153.65 interrupts/sec
CPU 1:
Vector 0xdd(TMR): 384.84 interrupts/sec
Vector 0xde(IPI): 236.08 interrupts/sec

Twimfy · Jan 20, 2014

Sounds like one of the thermal sensors on the logic board has failed. I had a 2010 MBP that did exactly what you are describing.

Run an Apple Hardware test. You'll see an error code for this issue usually.

GoSUV · Jan 20, 2014

Thanks for your help. I do realize this is a very old MBP, but currently I don't see the need to replace it unless something catastrophic were to happen to it. This machine ran fine under Mountain Lion - not the fastest machine, but adequate for what I do.

Now I'm wondering if rolling back to ML would get rid of this issue - would just restoring from a Time Machine backup be what's needed?

Would deleting one of the default kext's in the system library be a valid hack/workaround for this problem? I know it sounds risky, but this is an old machine, and if anything works I'm willing to give it a try.

Also, does cleaning up dust inside the machine help? I can buy a can of compressed air for mere dollars and give it a good blast - if it doesn't help at least I would not have spent too much.

SlCKB0Y · Jan 21, 2014

GoSUV said:
Thanks for your help. I do realize this is a very old MBP, but currently I don't see the need to replace it unless something catastrophic were to happen to it. This machine ran fine under Mountain Lion - not the fastest machine, but adequate for what I do.

Wouldnt it be better to do as the previous poster suggested and check if you have a hardware issue rather than sticking your head in the sand?

Twimfy · Jan 21, 2014

SlCKB0Y said:
Wouldnt it be better to do as the previous poster suggested and check if you have a hardware issue rather than sticking your head in the sand?

Damn straight. There are far too many people who blame an OS upgrade for a hardware failure (kinda sick of seeing reviews on the Mac Appstore saying "Mavericks ruined my machine!!!") more often than not it's co-incidental.

I'm 99% certain this is a thermal sensor failure. Only way to fix the machine is a logic board replacement. I hope for your sake that I'm wrong but I'd definitely rule it out first before you spend ages doing a time machine restore etc.

If you do decide to restore the system, time machine is likely to just take you back to Mavericks again depending on how old your backups are. They're not backwards compatible.

GoSUV · Jan 21, 2014

I finally found my original Software Install DVD's that came with the machine - that was way back from 2007 - and ran the Apple Hardware Test. Voila. A hardware fault was detected.

The error code is:
4MOT/1/40000002: Left side

So this sounds like one of the cooling fans inside the computer. I downloaded iStat, and confirmed it was the left side fan that has failed, as it shows it is running at 0 rpm while the right sided one is at 2000 rpm.

So this all came together making sense now. One of the cooling fans has failed. The OS is trying to protect the CPU cores by occupying it with some mundane loop, so that it won't be stressed too much as the cooling capacity has been reduced to half. The right sided fan has been switched to on most of the time - including when the computer's lid is closed and supposed to be "sleeping".

This is quite clever actually, and this happened right around the time after I have updated to 10.9.1, so this was wrongly attributed to being a bug with Mavericks. Now having said that, it still doesn't mean Mavericks is off the hook with the sleep/wake problem

Now my question is, how much roughly would be the cost to fix the cooling fan? This is a circa 2007 MBP and is obviously out of warranty, so I will have to fork out the money and pay for the repairs. If it is too much, I may be looking at a new one or some slightly used ones as a replacement. Or I can just live with using only a single core and the constant noise of the other fan always running...

Twimfy · Jan 23, 2014

Providing it is just the fan and not the circuitry that drives it. It shouldn't be too expensive to buy a fan on eBay (or from a third party parts store) and fit it yourself using a decent guide.

Strikerblob · Jan 26, 2014

My kernel task process used to go 100% when i wake the system from sleep. I had this issue in my Macbook Air 2013 with Maverick 10.9.1. But this seems to be fixed in 10.9.2 beta versions. Hope this does not bring more audio issues as currently i get too many audio related issues with Maverick

chip1 · Apr 4, 2015

ElectricSheep said:
Something else that can be done to investigate: In the Terminal, run the following command:

Code:

sudo sysdiagnose -f ~/Desktop/

It will produce a gzipped archive on your Desktop. Double-click to open and look for the following file:

Code:

powermetrics.txt

There is a section in this file called "Session Interrupt distribution". Copy and paste that section here.

Dear sir,

I have the same Kernel Task panic problem.
I have followed the steps you provided.
I would be grateful if you could assist me in this matter:

**** Session Interrupt distribution ****

CPU 0:
Vector 0x46(SMC): 1.69 interrupts/sec
Vector 0x49(MacBookAir6,1): 3.14 interrupts/sec
Vector 0x72(IGPU): 31.81 interrupts/sec
Vector 0x73(HDAU): 0.00 interrupts/sec
Vector 0x74(XHC1): 80.50 interrupts/sec
Vector 0x75(pci8086,9c3a): 0.07 interrupts/sec
Vector 0x76(HDEF): 1.50 interrupts/sec
Vector 0x77(CMRA): 0.02 interrupts/sec
Vector 0x78(ARPT): 41.22 interrupts/sec
Vector 0x7d(NHI0): 0.31 interrupts/sec
Vector 0x7e(SSD0): 17.44 interrupts/sec
Vector 0xdd(TMR): 256.75 interrupts/sec
Vector 0xde(IPI): 193.07 interrupts/sec
CPU 1:
Vector 0xdd(TMR): 176.42 interrupts/sec
Vector 0xde(IPI): 203.07 interrupts/sec
CPU 2:
Vector 0xdd(TMR): 168.74 interrupts/sec
Vector 0xde(IPI): 223.85 interrupts/sec
CPU 3:
Vector 0xdd(TMR): 173.50 interrupts/sec
Vector 0xde(IPI): 213.59 interrupts/sec

**** SMC sensors ****

CPU Thermal level: 255
IO Thermal level: 50
Fan: 6500 rpm (annoying) (39.4 dBA)
CPU die temperature: 42.97 C
Bottom skin temperature: -128.00 C
Drive 0 temperature: 44.50 C

10.9.1 kernel_task hogging one CPU core 100%

macrumors regular

macrumors 6502

macrumors regular

macrumors 6502

macrumors regular

macrumors 6502

macrumors 6502

macrumors 68040

macrumors regular

macrumors 6502

macrumors member

macrumors 6502

macrumors regular

macrumors 6502a

macrumors regular

macrumors 68040

macrumors 6502a

macrumors regular

macrumors 6502a

macrumors newbie

macrumors member

Our Staff