unsigned long geek = random();

As part of my ongoing project to get XFree86 working on a NetBSD/alpha system with a commodity PCI video card, I need to do a native build of XFree86. PR 29882 explains why the XFree86 X server is not included by default in the NetBSD release engineering releases, hence the need for my native build.

One slight potential fly in the ointment is that all my NetBSD source trees are stored on my source server and mounted read-only via NFS on the systems that need it. To build XFree86 with a read-only source tree requires a little trickery, but the procedure is nicely explained in the Building XFree86 from a Source Distribution guide (see page 3 onwards). The idea is to create a shadow tree containing symlinks to all the files in the original tree and using that to build instead of the original tree. It’s quick to set up and works very well.

Now to get a decent PCI video card…

As a follow-up to yesterday’s post about XFree86 on NetBSD/alpha, I was pointed in the direction of these two very useful references:

• Digital AlphaServer XFree86 Code
• Tested Good Video cards

It seems like a lot of commodity PCI video cards Just Work(tm) with XFree86 in Alpha systems, but just for safety’s sake I think I’ll stick with one of the known good cards. PCI Radeon 7000s can apparently be had for R300 (about $45) from a local computer reseller – I’ll go and check them out tomorrow and probably pick one up. Getting the card locally will probably cost the same as eBaying one, but it’ll certainly be a lot quicker.

Two weeks ago Jonathan collected his “new” Alpha – an AlphaServer 800. Of course, being the good chap he is, he promptly loaned it to me for a few weeks. It’s a nice machine: 500Mhz EV5 (21164a) CPU, 1GiB RAM, 2x9GiB SCA drives, CD-ROM and 4/8GiB DDS2 tape drive.

The machine was running FreeBSD 5.2.1, which I promptly replaced with NetBSD 3.0. Installation was fairly straightforward, once I had correctly identified the CD-ROM drive (the AlphaLinux SRM HOWTO is useful in this regard).

After using the machine for two weeks (and somehow destroying my only working Alpha in the interim), I decided to buy the machine from him for the price he paid for it (nice chap that he is, he agreed to sell it to me at no profit).

Now to get x.org working on it, with a good PCI video card (preferably something that supports two heads and DVI)…

New York City BSD Users’ Group have put a number of their talks online in mp3 format and a number of them make for great listening. One of my favourites (and particularly relevant in light of yesterday’s post on the subject) is Michael Shalayeff’s talk about porting OpenBSD to PA-RISC . Grab it here.

For the past few days I’ve needed an OpenBSD machine to test some IPSec code I’m busy working on (more on that in a few days). At Jonathan’s suggestion, I toyed with using a VMware virtual machine, but this morning decided to use a spare HP B132L I have lying around instead. Unfortunately NetBSD‘s hp700 port is not yet production-ready, so the machine had been running HP-UX 10.20. It’s a fairly nice mid-90s vintage machine – 133Mhz PA-7300 PA-RISC CPU, 64MiB RAM, 4GiB IBM narrow SCSI drive and Visualize-EG graphics. It could do with a bit more RAM, but 64MiB is more than adequate for my purposes.

Getting OpenBSD/hppa installed was pretty easy, but I managed to trip myself up a few times along the way:

• Plugging the wrong cable into the serial port means the console output isn’t going to be visible, no matter what the terminal settings are.
• Mixing and matching RJ45< ->DB25 adapters is not a wise thing to do when in a hurry.

To network boot the machine it was simply a matter of configuring my DHCP server to tell the HP to load the LIF image served by my tftp server. About half and hour after booting the installer I had an OpenBSD/hppa 3.8 machine on my network.

For those who enjoy such things, here’s the dmesg output.

After trying unsuccesfully to trade it to a friend a few months ago, yesterday I decided to fire up my AlphaServer 2100. It’s not a high-spec machine, with only a single 190Mhz EV4 CPU (the other CPU board failed a few months ago), 512MiB RAM and half a dozen 2GiB drives on a DAC960, but I thought it would be nice to at least get NetBSD installed on it.

I dug out a known-working NetBSD/alpha 3.0 CD and after a bit of fiddling, got the bootloader to load and uncompress the kernel. After decompressing, the machine appeared to hang. After waiting a few minutes, I hit the reset button, at which point things took a turn for the worse… The LCD status panel stopped displaying anything and the monitor connected to the VGA display remained blank. The fans were spinning, the disks had spun up and the network card LED was lit. I power-cycled the machine – same result. After reseating all the cards and even running the machine open for a brief period to look for status LEDs inside (didn’t spot any), I decided to hit Google.

I seems as if a few people have had the same problem, most notably Zoon PHAM (see this mail to Tru64 UNIX Managers), but no-one seems to have any possible solutions. This is rather disappointing – this is the only Alpha I own (although I currently have an AlphaServer 800 on loan, a machine that has rekindled my interest in Alphas), and they’re not particularly easy to come by here in South Africa.

A few days ago I started using RAIDframe on one of my NetBSD i386 systems. I now have my CVS and subversion repositories and my various BSD source trees housed on a software RAID1 array.

One thing that concerned me a little was the possibility of the disks in the array being renamed if I added additional storage to the machine. The two disks that make up the array are the master drives attached to the two channels on a Promise PCI IDE controller. If I used the default approach of dynamically naming the IDE disks, the two disks would be named wd0 and wd1. If I added a slave on the first channel, it would become wd1 and the old wd1 would become wd2. As you can imagine, this isn’t a good thing, particularly as my array is not set up to autoconfigure (it’s brought online by /etc/rc.d/raidframe, which uses a configuration file in /etc).

To prevent any potential disk-renaming problems, I decided to I decided to hard-wire the IDE devices to ensure that if I install additional disks, the drives don’t get new device names. It’s quite simple – the kernel just needs to be told to name devices based on their positions on the IDE bus instead of allocating names dynamically.

I used the following in my configuration file:
pdcide0 at pci? dev ? function ?
pdcide1 at pci? dev ? function ?
atabus0 at pdcide0 channel 0
atabus1 at pdcide0 channel 1
wd0 at atabus0 drive 0 flags 0x0000
wd1 at atabus0 drive 1 flags 0x0000
wd2 at atabus1 drive 0 flags 0x0000
wd3 at atabus1 drive 1 flags 0x0000


The two IDE disks in the machine are now wd0 and wd2 and adding or removing disks doesn’t affect the device names (I’ve tested this!). The same principle applies to SCSI disks (and any device, in fact). In the case of SCSI, it’s possible to wire a specific disk device name to a specific SCSI ID, rather than having the disks named in the order in which the kernel identifies them.

I was looking for some good NetBSD stickers to decorate some of my systems when I came across the NetBSD Project CafePress Store. They have a large selection of NetBSD-branded items, included some quite unusual ones (anyone for a camisole or tanga with the NetBSD logo on it?). A portion of the proceeds go to the project, so go and grab your goodies now!