8 Replies Latest reply: Mar 3, 2013 8:34 PM by Linc Davis
lundman Level 1 (0 points)

Plenty of threads on the kernel_task issue, even here. But most of them are on MacBooks, and seem to think it is heat related. I see this issue twice a month or so, on a MacPro.




# top -u


kernel_task  400.7 109 hrs  91/12 073725M0B 1018M
54170  top      21.5  00:00.63 1/1   024+36+3056K+ 220K-  3812K+
22871  seamonkey12.1  05:40:20 31/1  3363-   18285- 754M-  156M-  1176M-
50207- iTerm    9.9   18:26:24 8/2   4171-   383-   36M-   28M-   65M-



Brendans hotkernel say:


mach_kernel`pmap_remove_range                           8   0.1%
mach_kernel`0xffffff801a921080                         10   0.1%
mach_kernel`lck_mtx_lock                               22   0.2%
mach_kernel`pmap_flush_tlbs                            37   0.4%
mach_kernel`_rtc_nanotime_read                         55   0.6%
mach_kernel`machine_idle                             4182  42.3%
mach_kernel`ml_set_interrupts_enabled                5408  54.7%
  • XENiCraft Level 2 (265 points)

    Could you please provide a screenshot of where you see this in activity monitor?

  • Linc Davis Level 10 (184,545 points)

    The kernel is using excessive processor cycles. Below is a partial list of causes for this condition.

    Thermal overload

    This can be due to accumulation of dust, high ambient temperature, or to the malfunction of a cooling fan or temperature sensor. The kernel tries to compensate by throttling back the CPU's. You might see messages like the following in the Console window:

    SMC::smcHandleInterruptEvent WARNING status=0x0 (0x40 not set) notif=0x0

    The timestamps of those messages (if any) indicate the times, since the log was last cleared, when a processor was being throttled because of high temperature.

    Note that if the problem is caused by a faulty sensor that reads too high, there may be no actual overheating.

    The Apple Hardware Test, though not very reliable, is sometimes able to detect a bad fan or temperature sensor.

    Using Apple Hardware Test



    Transferring large amounts of data to or from an encrypted disk image or FileVault volume puts an extra load on the kernel. If both the source and the destination are encrypted, the load may be doubled. If you transfer data from an encrypted disk image on an encrypted partition to another such image on another encrypted partition, the load may be quadrupled.

    This issue probably doesn't affect late-model Macs with an Intel i-series, recent Xeon, or later processor. Those processors support hardware-accelerated encryption. You can determine what kind of processor you have by selectingAbout This Mac from the Apple menu in the menu bar.

    Installed software

    User-installed software that includes a device driver or other kernel code may thrash the kernel. Some system-monitoring applications, such as "iStat," can also contribute to the problem. You can test for this possibility bycompletely disabling or removing the software according to the developer's instructions, or booting in safe mode (with the shift key held down at the startup chime.) Note, however, that disabling a system modification without removing it or booting in safe mode may not be as easy as you think it is.

    Corrupt NVRAM or SMC data

    In some cases the issue has reportedly been resolved by resetting the NVRAM or the SMC.

  • lundman Level 1 (0 points)

    Sure, it has happened again, 4 threads running wild in kernel_task.


    Screen Shot 2013-03-04 at 12.01.21 .PNG


    There is nothing in Console about smb. Some random messages are:


    03/04/13 11:35:55.000  kernel[0]: aio_queue_async_request(): too many in flight for proc: 16.

    03/04/13 11:29:11.206  sandboxd[80410]: ([80409]) mdworker(80409) deny mach-lookup com.apple.ls.boxd

    03/04/13 11:19:48.000  kernel[0]: CODE SIGNING: cs_invalid_page(0x1000): p=80366[GoogleSoftwareUp] clearing CS_VALID


    Nothing that looks particularly interesting.


    Nothing encrypted on disks, and nothing wrong with hardware. Reboot will always fix it, and it comes back ~3 weeks later.


    Uptime at the moment is just 35 days.


    It is a MacPro, not a laptop.

  • Linc Davis Level 10 (184,545 points)

    You have at least two system modifications that could be contributing to the problem: VirtualBox and Viscosity.

  • lundman Level 1 (0 points)

    Sure, I can quit both of them if you want, doesnt change things once kernel_task has freaked out. I can also tell you that it happens without VirtualBox running. I write kernel kexts, so I use a VM to test them.


    But, it would be harder to prove without viscocity since it is my Internet access.


    dtrace of kernel_task has not led me to believe either is involved though.

  • Linc Davis Level 10 (184,545 points)

    You're in a better position to solve this problem than I am. You can quit Viscosity and see whether the CPU usage drops.

  • lundman Level 1 (0 points)

    Yep, I suspect Apple's view is just to reboot "every 30 days isn't too bad". Oh well, at least I made my report, maybe it will be fixed sometime in the future



  • Linc Davis Level 10 (184,545 points)

    I have never seen the problem you describe on any of my Macs running ML. And you haven't made a report to Apple by posting here. If you feel you've found a bug, report it on the developer site. But unless you can specify a way to reproduce on a clean installation of OS X, without third-party kernel extensions, you'll be wasting your time.