4 Gigabytes of Fun!

It sometimes seems that no procedure involving a computer ever turns out to be as straightforward as you initially think it will be.

The desktop I have at work is a pretty nice system, a Dell Precision T3400 quad core with 2GB of RAM.  It's plenty fast, but with some of the memory hogging software I run all the time (a Windows virtual machine, Eclipse IDE and Firefox), sometimes it gets bogged down not with the processor but with swapping stuff in and out to disk.  RAM is a pretty cheap upgrade, and I managed to get a RAM upgrade for my machine to 4GB.  Yay!  Problem: Ubuntu  only recognizes 3.2GB of RAM, though the BIOS clearly sees all 4GB.  Boo!

Well, I have the 32 bit version of Ubuntu installed, not the 64 bit version.  Never occurred to me to install the 64 bit version (and never would have made a difference before today).  Didn't relish the thought of reinstalling to get the 64 bit version, so I did some googling.  

The first line of attack that I ran across involved tweaking BIOS settings.  I found many suggestions to look for some kind of memory remapping setting in the BIOS.  I couldn't find anything in my BIOS (a Dell Precision T3400).  I noticed the BIOS was a few versions of date, so I updated that, but it didn't seem to make a difference.  (Aside: very pleased to see that I could download  a Linux version of the BIOS updater, which was basically just a single file that you chmod +x and run as root in single user mode.  Good on ya Dell!)

A little more googling and I discovered that some Linux kernels have support for Physical Address Extension, which is a workaround for 32 bit OS's to allow them to address more than 4GB of address space. Of course, I only wanted to see 4GB of RAM, not more, but to do so requires more than 4GB of address space because of other things that have to be mapped to some memory location, like video RAM, etc. Poking around some more, it seems that the default Ubuntu desktop kernel does NOT include this support. Further confirmation provided by this entry in /var/log/dmesg: Use a HIGHMEM64G enabled kernel. The solution is to install the server version of the kernel, which does provide that support.

So to the keyboard I ran (OK, that's a lie, I was already at the keyboard) and typed:  

apt-get install linux-image-server

Success! Victory is mine! But wait, upon rebooting, disaster struck. My X server kept trying to initialize over and over, and finally came up in an extremely low resolution mode and said it couldn't detect my video card anymore. Whaaaaaaaa????

At first I started wondering if something weird was going on, like maybe it was somehow remapping the address of the video RAM in a way that the Nvidia driver didn't like, but it turned out to be much simpler. After some further googling, it turns out that you need to install some kernel modules for the nvidia driver I'm using. I guess those modules must have already been installed for the generic version of the kernel, but not the server version. So a couple more terminal commands:

sudo nvidia-xconfig (to put my X configuration right again)

sudo apt-get install linux-restricted-modules-server (to provide the module support needed for the video driver)

Then, a quick reboot. There was one more minor hiccup, which actually took care of itself. When I fired up VMWare it said it needed to recompile some kernel modules (which it always does whenever you upgrade the kernel). One really nice thing in the VMWare 6.5 betas is that it just takes care of this for you, and gives you feedback about this operation in the GUI, with no action required on your part. No more going to the command line and running the old vmware-config.pl script.

I write this entry in the hopes that it will save someone else time in the future, as they can find all this info in one place, instead of the dozens of places that I had to gather it all from.