[Technology] kernel_task consumes almost 100% of CPU on Mac OS X

The Problem

A friend spilt tea on their MacBook Air and this has probably killed their battery.  In an attempt to see if it was just a firmware problem, they attempted an SMC reset, which resulted in their computer becoming incredibly slow (and the battery still not working).  Reviewing CPU usage showed that kernel_task was opaquely consuming all available CPU cycles.  Oh nos!



(spoiler: this post does not end in a working battery, just in eliminating the excessive CPU usage)

Possible solutions

I googled a bit.  Some people recommended trying a PRAM reset (which did nothing (to do it, use command + option + P + R at boot after the tone, until you hear a second tone)).  Starting up in safe mode to see if disabling all non-core kernel extensions helped did not (to do that, hold shift at the start up tone until the grey Apple logo appears).   Finally, someone suggested disabling one of the plists for power management in one of the kernel extensions.  The idea there was that the kernel thought the computer was overheating and was trying to take misguided measures to deal with it that resulted in total CPU consumption (and more heat).  I thought this might be relevant, not due to heat, but because a part of the device was no longer working, and perhaps the kernel didn't understand and was making a bad decisions.

The solution

This turned out to be the right idea.  Under /System/Library exist many kernel extensions, and the relevant one is the IOPlatformPluginFamily.kext.  There suggestion was to disable the plist for your model of computer that was located in that kext's Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext (a sub kext!).  First, his MacBook Air didn't have a relevant plist, and second, disabling that entire kext (simply by renaming it to something else so Mac OS X wouldn't find and load it) did not help.



I then tried disabling IOPlatformPluginFamily.kext altogether, and it worked!  Thinking that a bit too brutish, though, I re-enabled it, and tested disabling a variety of its sub kernel extensions (under /System/Library/IOPlatformPluginFamily.kext/Contents/Plugins) to see which one was the culprit.



Here are the sub kernel extensions within IOPlatformPluginFamily.kext:

• ACPI_SMC_PlatformPlugin.kext


• AppleSMCPDRC.kext


• IOPlatformPluginLegacy.kext


• X86PlatformPlugin.kext


• X86PlatformShim.kext   < this is the one I had to disable.

Steps

Here are the steps for disabling them.  Pardon any errors, as I'm doing this from memory and photographs after the fact.



1. Open a Terminal (Applications > Utilities > Terminal).  This took a dreadfully long time, given how slow the computer was running.

2. Run these commands (text precede by a # is just a comment)

> cd /System/Library/IOPlatformPluginFamily.kext # enter main kext directory> cd Contents/Plugins  # enter kext's plugins (other kexts)

> ls  # list the available kexts

ACPI_SMC_PlatformPlugin.kext
AppleSMCPDRC.kext
IOPlatformPluginLegacy.kext
X86PlatformPlugin.kext
X86PlatformShim.kext

> sudo mv X86PlatformShim.kext X86PlatformShim.kext.disabled # rename the culprit .kext (after trial and error) to something different so it can't be loaded (doesn't need to add .disabled specifically); start  with sudo to do this as the root user (or you won't have permission); this will request your user password

3. Then, restart your computer to see if it works.



You should be able to actually rename /System/Library/IOPlatformPluginFamily.kext as a quick test to start to see whether a problematic .kext exists within it, and then try this (or maybe ACPI_SMC_PlatformPlugin.kext's specific plist, depending on your actual problem) to be more specific (who knows, some of the plugins might actually be there for a reason ;). 

[Technology] gethostbyname failed

I was trying to set up a Festival speech synthesis server to work with Speech Dispatcher and a Rhythmbox plugin I'm working on. Speech Dispatcher couldn't connect to it. I tried connecting to the Festival server with the Festival client, and that didn't work either, instead giving me an error "gethostbyname failed". I investigated and saw it should be trying to connect to localhost at 1314. I verified that my firewall and selinux weren't involved. Then I finally peaked at my /etc/hosts file, and sure enough a change I made a couple weeks ago broke it. I reverted that, and now it works again. Yay!

[Technology] Resizing my encrypted, ext4 file system

I normally just upgrade my Linux distro from its semiannual release in place.  I keep my existing file system and just upgrade packages en masse.   I don't usually reformat and restore files from a backup.



For Fedora 17 last year, though, I wanted to upgrade all my file systems from the ext3 format to ext4.  It's "better".  You can do it in place, but there are attributes that won't apply to any old file system entries, only to new ones (new files that get added).  I could in theory have upgraded it in place, and then just copied files back and forth from another drive, but whatever.  Clean start.  I backed up all my personal files, and reformatted the whole disk as ext4, and moved it back.



Now, the disk setup was this.

• 0.5GB boot partition (device: /dev/sda1, mount point: /boot)


• 465GB volume group (device: /dev/sda2)




• 4GB swap partition


• 24GB ext4 root volume (mount point: /)
  This is where all the system files go, like programs.


• 200GB LUKS ext4 volume (mount point: /home)
  This was my primary file system for personal files.  It's encrypted so that if someone steals my laptop, they won't be able to read my data. :)


• 237GB ext4 volume (mount point: /home2)
  This was a secondary one.  I wasn't sure whether the LUKS encryption on /home would slow down IO-heavy activities, like managing media files.  I didn't mind having things like videos and music stored unencrypted.

Ultimately, though, I found /home2 was unnecessary.  /home was adequately fast for my media.  While I have a laptop, it's 7200RPM rather than 5400RPM, so that helps.  Thanks to my photography habit, I found /home getting almost full, only 1GB free!  I considered moving my music collection to /home2, but decided instead to try to get rid of /home2 and expand /home over that space.



I used system-config-lvm to delete /home2 and then used it to resize /home over top it.  However, that alone did not resize my file system to cover it.  Interestingly, gnome-disks reports the LUKS volume and ext4 file system as taking up the full space, but df reports the ext4 file system as taking up only 200GB.  Uh oh.



So, I read this tutorial on Ubuntu forums about resizing encrypted file systems, and found the one step I still needed to take.  Apparently, system-config-lvm won't really resize the ext4 file system, even though gnome-disks claims afterwards that it larger.  So, I just ran resize2fs on it.  I used mount to figure out which volume it was on (mine was /dev/mapper/luks-blah-blah-blah) and then ran resize2fs /dev/mapper/luks-blah-blah-blah, while it was even mounted (!).  Hooray for live resizing.  It worked well, and after a reboot still worked too.

[Technology] Efficiency!

I was using a script for a project that applied a bunch of transformation and filtering rules to some data.  There are only about 60 rules right now, and there is an average of 272 data records each day.   I originally wrote this quickly in a bash script using the terminal commands sed (for replacing a matched pattern with some string) and grep (for filtering based on a matched pattern).



Running it in a given month gets progressively longer as the month goes on, and it was taking on average over 5 minutes (!) to run those 62 rules.  Applying all the rules to each data record was taking almost a full second each.  This wasn't really scalable.



So, today I ported the script to vala, which is a C#-like language that compiles down into C (which is then compiled into native code).  This promises to be much quicker than interpreted code to begin with.  The run time once converted was less than 1 second.  That was a pleasant surprise.



Some of the fun was moving the transformation rules into their own file (XML), separate from the code, and making sure all the Regex objects were created once at the start of the program and then applied to all later data.



To make it still better would probably involve parsing the data records into a structured form from the start, rather than just using regular expressions to transform data strings.  Then creating a couple different type of rules for specific fields.  But this is good enough for now. :)

[Technology] Silly mistakes

Wondering for a day why my Linux Live USB key won't boot on my Asus Eee Top and then realising that the Linux image is 64 bit and the Eee Top is 32 bit.

[Technology] Login with Facebook

I never log in to a foreign website with Facebook.  Part of the reason is because it's never clear how much true access the website gets to your identity and data, even unintentionally.  I also avoided Google Connect.  I'd much prefer having an identity provider (I.me) which took a step to verify me, and then only gave other websites a consistent token that could not be correlated with my usage between other websites.  I'd be consistent to the website I'm signing in to (I could be 9017 to FreeTheGoats.go) but even if they shared their logs of users with another (EatGlass.net, where I'd now be 7103), they wouldn't be able to go, "A-ha, he likes eating glass and goat liberation!"



I bring this up because of Aviva, and in particular their Georgian Bay Turtle Hospital.  They need an account to at least know your votes are unique (though they'd also like to contact you), but I don't want to create yet another account (I probably will, for the turtles you know) and I don't want to use the alternative of logging in on Facebook.  I'd like another provider to just go ("This is 1097, who you've seen before, so they're not voting a second time today, but they can again tomorrow.")  It's a little reminiscent of OpenID, but that's more identifiable, with named URIs.  Sigh.