If you're one of the many people that have been trying to contact me for the last couple of days, I appear to have fallen off the surface of the planet. I feel that I should probably explain why I've gone out of contact. On Saturday night I got on a red-eye flight from Phoenix to Atlanta and then on to Rochester after a three hour layover. After landing and complaining about my lost luggage, I sat in the car for two hours on the ride back to Corning. Needless to say, when I got home I was exhausted.

On Monday I started on the complicated and time consuming task of rebuilding every computer on my network here. In the process of rebuilding things, I took yt.neohippie.net offline. yt was hosting my website, asterisk, and jabber which explains why I wasn't online. I spent the better part of the day attempting to get NetBSD to run as a Xen 3.0 domain 0 host. By the end of the day, I had a NetBSD box that would crash upon startup. Not very usable.

Tuesday morning, I decided to scrap NetBSD for the time being and built a Gentoo box with Xen. The install went relatively smoothly as I combined the Gentoo Handbook and a Howto on installing Xen into a set of instructions in my mind that worked very well. I'll probably document this process a bit better when I have some free time. By lunchtime on Tuesday, I had a working Gentoo domain 0 and was about halfway through building the domain U image. By the end of the day, I had running virtual machines with automounted home directories, internal DNS, and a second domain 0 box with working live migrations between the two.

When I woke up this morning, I started hacking away at getting MythTV running inside a domU machine. Building and installing MythTV went fairly well. I had to recompile the domU kernel a couple of times to get the ivtv modules to build. I am now stuck on loading the ivtv drivers. The module appears to load into the kernel, enumerates the hardware, and attempts to create a DMA buffer to the card. For some reason, modprobe segfaults here. I found some mailing list messages that describe a similar problem with Xen 2.0 and a working patch. I would expect that the patch has been merged into Xen 3.0 by now but it still doesn't work.

I took a look at the Xen PCI DMA kernel code and I think I've found the method that is causing the problem (dma_map_single()) and have done a quick and dirty hack that I hope will fix the problem and am waiting for the kernel to finish compiling now.

The goal of all this hackery is to get all of my servers condensed into two boxes so that when I move back into the dorms in a month, I won't have piles of computers all over the place. Once I've got my servers setup and squared away, I've got a sonar sensor that I'm going to mount on my RC car for data collection. Hopefully I'll get something usable out of this and will be able to start writing some AI and mapping algorithms to run on the car to make it autonomous.

Finally, the Summer of Code is coming to an end and I've only got a few small tasks to finish up. The web templating needs to be finished in forms.py, Atom and RSS feeds need to be checked for validity and tweaked if necessary, a quick and dirty archive summary needs to be written, and syslog messages need to be fully implemented. None of these are large tasks, I just need to sit down and knock them out. I should have time for this sometime next week.

Next post - Summer of Code - Days 32 - 48