If you have a MacBook Pro with several gigabytes of RAM, you may have noticed that Mac OS X will lock up when you try to wake the laptop up. This can be very frustrating and requires you to hold the power button in for 5 seconds and turning it back on.

I run 2 or 3 VMware Fusion virtual machines at the same time and that eats up a ton of RAM, but it’s OK since my laptop has 8GB of memory. My machine would lock up when I tried to wake it up. I found that it would sometimes be OK leaving 1 virtual machine running, but if I left 2 running, it would almost always lock up.

So, I did some research and discovered the problem has to do with Mac OS X’s power management, specifically the hibernatemode. The value is a bitfield that has the following options:

• 0 (0000) Disables SafeSleep. Memory state is maintained until battery power is gone in which case the computer turns off completely.
• 1 (0001) Enables hibernation, writes memory contents to hibernation image, and immediately goes to sleep.
• 3 (0011) Maintains memory state while sleeping, but when the battery power is nearly gone, it will write the contents of the memory to hibernation image.

On laptops, the default value is 3. On desktops, the default is 0.

To fix the problem, you simply need to set the hibernatemode to 0. From a Mac OS X terminal, run the following:

sudo pmset -a hibernatemode 0

Then reboot your laptop and enjoy lock-free waking up!

At this point, hibernation is disabled and that means you can delete the hibernation file and free up a couple gigs of disk space!

sudo rm -f /var/vm/sleepimage

One side note, Microsoft Windows actually disables hibernating on computers with 4GB or more of RAM. They claim that it took longer to restore the memory state from disk than to just do a normal boot. I disagree since it takes a long time to spin up all your apps, virtual machines, and start being productive. I wonder if they discovered some technical issue that is what is causing the issues on Macs.

The new Parallels Desktop 3.0 for Mac is out! At first, everything looks great! Then I noticed my Cisco VPN Client v4.9 stopped working.

I tried uninstalling both the VPN client and Parallels, then reinstalling and everything worked until I rebooted. So, that wasn’t going to work. After doing a ton of digging around, I found this post that suggested a fix that works!

Bring up a terminal and execute an ifconfig -a:

$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
vmnet8: flags=8862<BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 172.16.91.1 netmask 0xffffff00 broadcast 172.16.91.255
        ether 00:50:56:c0:00:08
vmnet1: flags=8862<BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 172.16.197.1 netmask 0xffffff00 broadcast 172.16.197.255
        ether 00:50:56:c0:00:01
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether 00:17:f2:cd:20:02
        media: autoselect status: inactive
        supported media: autoselect 10baseT/UTP <half-duplex>
                10baseT/UTP vfull-duplex>
                10baseT/UTP <full-duplex,hw-loopback>
                10baseT/UTP <full-duplex,flow-control>
                100baseTX <half-duplex>
                100baseTX <full-duplex>
                100baseTX <full-duplex,hw-loopback>
                100baseTX <full-duplex,flow-control>
                1000baseT <full-duplex>
                1000baseT <full-duplex,hw-loopback>
                1000baseT <full-duplex,flow-control> none
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        tunnel inet  -->
        inet6 fe80::219:e3ff:fe06:93f0%en1 prefixlen 64 scopeid 0x7
        inet 192.168.1.97 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:19:e3:06:93:f0
        media: autoselect status: active
        supported media: autoselect
        vlan: 0 parent interface: <none>
        bond interfaces: <none>
wlt1: flags=41<UP,RUNNING> mtu 1500
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030
        inet 169.254.90.185 netmask 0xffff0000 broadcast 169.254.255.255
        lladdr 00:19:e3:ff:fe:69:37:c4
        media: autoselect <full-duplex> status: inactive
        supported media: autoselect <full-duplexv
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::21c:42ff:fe00:0%en2 prefixlen 64 scopeid 0xa
        inet 10.0.1.3 netmask 0xffffff00 broadcast 10.0.1.255
        ether 00:1c:42:00:00:00
        media: autoselect status: active
        supported media: autoselect
en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::21c:42ff:fe00:1%en3 prefixlen 64 scopeid 0xb
        inet 10.0.2.12 netmask 0xffffff00 broadcast 10.0.2.255
        ether 00:1c:42:00:00:01
        media: autoselect status: active
        supported media: autoselect

Find the interface that starts with “fw”. In my case, mine is called “fw0″. Next, shut off the interface:

$ sudo ifconfig fw0 down

fw0′s flags will now be 8822 and now the Cisco VPN client should work!

But what happens if you reboot? Oops! The fw0 interface comes back on. Disable the interface when the Cisco VPN subsystem is started:

$ sudo pico /System/Library/StartupItems/CiscoVPN/CiscoVPN

Then change the StartService() function to look like this:

StartService ()
{
    #disable fw0
    /sbin/ifconfig fw0 down

    if [ -d $CISCO_VPN_DIR ]; then
        ConsoleMessage "Starting Cisco Systems VPN Driver"
        kextload $CISCO_VPN_DIR
    fi
}

Test with a quick reboot and everything should work!

Thursday, April 19th, the latest rev of the Linux distro Ubuntu 7.04 (Feisty Fawn) was released. I wasted no time to download it and installing it in one of my trusty virtual machines.

I have a Macbook Pro and I use Parallels Desktop for Mac as my VM software. Installing previous Ubuntu releases was a piece of cake, but Ubuntu 7.04 was being a little “feisty” to install.

After trying the DVD, Desktop, and Alternative versions, I still had no luck. It was hard to tell what the problem was on the DVD and Desktop editions since they were live CDs and the screen just went blank. The Alternative version gave me a clue that the installer couldn’t load the CD/DVD drivers.

After doing some digging, I discovered there is a problem with both Parallels CD/DVD driver and the latest Linux kernel that ships with 7.04.

To get around the problem, I changed the OS Type to “Solaris” and OS Version to “Other Solaris” and then tried again to install Ubuntu.

Ubuntu’s installer found the drive without a problem and successfully installed the operating system. After the installation was complete, I shutdown the VM and changed the OS Type back to “Linux” and OS Version to “Other Linux kernel 2.6″. I have no idea if the CD/DVD drive works after changing these back, nor do I know if there are any issues with just leaving the OS Type as Solaris.

My hopes are that either a new kernel and/or Parallels releases an update to fix this problem. Honestly though, I have never used the CD/DVD drive in a Linux VM since everything I install is downloaded.

Has anybody else had this issue or come up with a better workaround?