kernel_task is using 100% CPU when waking from sleep

This might be an interesting lead... I have Audio Hijack Pro installed, as well Airfoil. Do other people experiencing the issue also have those apps installed?

In the mean time I have reverted to the previous AppleHDA driver as suggested by John_Raz, and will let you know if it has stopped the issue on my 2013 MBA.

This is very much an intesting lead. I have both AudioHiJack and AirFoil installed. Will check when I'm home by removing Soundflower.kext.

this might indeed be a lead: I also have soundflower installed (with which program could that have happened? deejaay? virtualDJ? VLC? Audacity?) and I only had that problem when Earpods were plugged in...

so there should be something wrong with the sound drivers... does one need soundflower for anything else except recording audio?

As far as I've read about it: it pipes sound from one application to another, which makes sense for audio hijack pro and other software that uses that functionality. I first got the suggestion from this thread: https://discussions.apple.com/thread/5434796?answerId=23360912022#23360912022

Apparently soundflower has not been updated in years and is implicated in crash reports.

I did a clean install of OSX 10.9 and had it happen on a mid-2013 MacBookAir.

I do have and use VLC.

I tried both the kext unload and the killall coreaudiod, and neither worked.

I'll add some more information here about my setup, as well as an interesting observation today. I do not use Soundflower, AudioHiJack, AirFoil, etc. I am on a brand new MacBook Pro Retina 13" (late 2013). Others have noted that even those models in-store (with obviously no 3rd party audio haxies installed) show these symptoms. So, these utilities could exacerbate the problem or even possibly reveal similar symptoms. But, I don't think those are the root cause.

For my part, I am using Bose QuietComfort 15 headphones. These headphones come with two sets of audio plugin cords: one that is a straight headphone cord and one that is a combination headphone/microphone/remote control cord. I have been using the combination cord the entire time I've seen this issue, and I consistently see this issue with kernel_task spiking every time I come out of sleep with the headphones connected with this combination cord.

Today, for grins, I tried using the regular headphone cord instead, after seeing the kernel_task issue several times already (with the combo cord). To my surprise, kernel_task spikes when coming out of sleep, but only for a couple of seconds - consistent with a sleeping system waking up. It then settles back down into the 1-3% neighborhood. I tried this multiple times, with the same behavior. I also noticed that, in the System Preferences -> Sound window, the Output stays the same no matter which cord is used (they both change to Headphones instead of Internal Speakers). But, when the combo cord is used, the Input changes from Internal microphone to External microphone. I thought, maybe the electrical contacts on the cords were different and triggering something, and they are. The combo cord uses 4 leads instead of just the 3 on the regular cord. No doubt, this is the detection mechanism for the microphone or remote control.

All that to say that the microphone is the only thing that appears to be activated upon insertion of the headphone cord. The kernel_task issue happens regardless of whether anything is actually played back on the headphones, so it seems to be an initial condition issue. Switching from Internal microphone to External microphone may be what is triggering this. Unfortunately, unlike my 2009 MacBook Pro, this 2013 MacBook Pro doesn't leave the option of Internal microphone once the headphones are plugged in. It is one or the other.

So, maybe the microphone detection is the root cause?

This is also what I found. However, kernel_task does go 100% even without headphones or with headphones without mic, but a lot less often. The newer MacBooks have dual mics for noise cancelation. Maybe it's related, who knows, newer Soundchips are the more plausible cause though.

I've manually installed Soundflower on Mavericks 10.9.1, late-2013 Retina MBP 13", with my code signing.

After that I had the sleep-wake problem once, so reloaded the kext, and it fixed. Since then it works fine without any problem.

I think reloading action would reset internal kernel states, regardless of what reloaded.

Howdy all. I posted an Apple bug report on the problem, and Apple has finally replied and is asking me to perform some diagnostic steps on my MacBookAir (mid 2013). However, I have regressed back to 10.8.

Is there anyone with an MBair that is willing to perform the steps and send the output to me so I can attach it to the bug report? If not, I will try to reinstall 10.9 next week some time.

These are the instructions Apple sent. If any of the MBP folks want to do this, I'm happy to attach that as well.

Please attach the output of 'sysdiagnose' collected while the problem is occurring or if not possible taken after the issue has occurred. 'sysdiagnose' can be triggered by pressing Cmd-Opt-Ctrl-Shift-Period, and it may take a few minutes to complete. When ready, the output will automatically be revealed in a Finder window (or it can be manually retrieved from /var/tmp)

Also, please include a full System Information Report.

To obtain a full System Information Report on OS X:

1. Select "About This Mac" from the Apple Menu

2. Click the “More Info…” button on the About This Mac window

3. Click “System Report…” on the next About This Mac window

4. Select "Save…" from the File menu (cmd-s)

5. Change the file name and save location as needed

6. Click the "Save" button

I got the same reply from Apple, will do the diagnostics sometime today (I have MBP Retina late 2013).

contact information please.

I posted that I sent my logs to them and they blamed it on a third party driver for Drobo which obviously nobody else here as a problem with so it's BS.

As for Soundflower, I checked my computer last night and even though I have AudioHijack and AirFoil, I do not have Soundflower.kext installed. So my problem exists without that extension.

My name with no spaces at gmail dot com.

I have exactly same kernel_task cpu over 100% fault.

My findings:

1. happens only when coming back from sleep-mode
2. sometimes cpu usage gets normal when I unplug the iphone earplugs and wait 5secs

   sometimes it doesn't matter

3. sometimes cpu usage gets to 100% even if I don't have earplugs connected
4. sometimes cpu usage gets to 100% about 30-45secs and then goes back to normal state when coming from sleep-mode

   this happens only without earplugs connected

5. that AppleHDA.kext unload / reload doesn't help IF earplugs are connected and cpu usage gets to 100%

   if earplugs aren't connected, it helps but only about 7/10 times.

6. if cpu usage gets to 100% and earplugs are connected I can wait even 10 hours and cpu usage still remains at 100%
7. if cpu usage gets to 100% and earplugs are not connected cpu usage gets back to normal:
   1. after about few hours
   2. sometimes when I close Google Chrome and wait 5secs

I have feeling that this might somehow connected to microphone connectors or drivers and that Google Chrome point 7.2 might be related cause I have Flash Player installed and that uses sometimes microphone. But this might just be a hunch.

Hope this can be resolved soon.

my computer:

Late 2013 Macbook Pro 13" retina. 2.6ghz, 16gb

I don't have flash and have the exact same symptoms. (though a have Chrome which I almost never use, with has flash but sandboxed)