apocryph.org Notes to my future self

Preparing The Highpoint RocketRaid 222x Driver Source Code

1. Go to the HighPoint RocketRaid 2220 download page, and download the FreeBSD open-source driver (at the bottom of the page). Do not get the FreeBSD driver; you must download the source code. As of this writing, the latest version was 1.01.
2. Extract the tarball into /usr/src/sys on a machine with the FreeBSD 6.0-RELEASE amd64 sources installed. This will create /usr/src/sys/dev/hptmv6 and /usr/src/sys/modules/hptmv6 and the files therein.
3. Edit the file /usr/src/sys/dev/hptmv6/osm_bsd.c in vi or some similar text editor. This file references a field (d_maj) in a kernel data structure (cdevsw) that is no longer used in the 6.0 kernel (see What happened to the “d_maj” member of “struct cdevsw” in CURRENT? on the FreeBSD mailing list archive). Until this broken reference is removed, the driver will not compile.

   As of version 1.01 of the driver source, the offending line was 1117 in osm_bsd.c. The line number could vary with subsequent versions, but the region around the problem looks like this:

    #if __FreeBSD_version>501000
            .d_maj =        MAJOR_AUTO,
    #else
            .d_maj = HPT_DEV_MAJOR,
    #endif
   

   This entire #if/#endif block must be removed or commented out. I prefer to comment it out, replacing the above with this:

    /* commented out by anelson; d_maj deprecated in 6.0
    #if __FreeBSD_version>501000
            .d_maj =        MAJOR_AUTO,
    #else
            .d_maj = HPT_DEV_MAJOR,
    #endif
    */
   

   The /* and */ sequences denote a comment block in C; everything between the two sequences will be ignored by the compiler.

4. The Makefile in /usr/src/sys/modules/hptmv6 needs to be tweaked a bit as well. Replace its contents with this, below:

    HPTMV6= ${.CURDIR}/../../dev/hptmv6
    .PATH: ${HPTMV6}
   
    KMOD = hptmv6
    SRCS = opt_scsi.h opt_cam.h bus_if.h device_if.h pci_if.h os_bsd.h os_bsd.c osm_bsd.c hptmv6_config.c
    OBJS = hptmv6_lib.o
   
    .if $(MACHINE_ARCH) == "amd64"
    HPTMV6_O = amd64-elf.hptmv6_lib.o.uu
    .else
    HPTMV6_O = i386-elf.hptmv6_lib.o.uu
    .endif
   
    hptmv6_lib.o: ${HPTMV6}/$(HPTMV6_O)
                uudecode -p <  ${HPTMV6}/$(HPTMV6_O) > ${.TARGET}
   
    .include <bsd.kmod.mk>
   

   Most of the changes are cosmetic, but one important change is to the path to the .uu file; as downloaded the path is ../../dev/hptmv6, which won’t work during kernel builds, since /usr/src/modules/hptmv6 isn’t the current directory. Instead, the makefile above uses ${.CURDIR}/../../dev/hptmv6, which will always resolve to the correct dev/hptmv6 path. I borrowed this form from the hptmv driver, for the RocketRaid 18xx series ATA RAID cards, which was already in the kernel source tree in /usr/src/sys/modules/hptmv, and has a very similar structure to that of the hptmv6 driver.

5. Create a new kernel configuration based on GENERIC, and make the modifications as instructed in the Readme file that ships with the RocketRaid 222x driver tarball. Specifically, the changes are:
   1. Copy the GENERIC file in /usr/src/sys/i386/conf (for i386 targets) or /usr/src/sys/amd64/conf (for amd64 targets; the target I’m interested in), to a new file in the same directory, with a different name. This new name will be the name of the custom kernel; I use CUSTOM_AMD64_HPTMV6.
   2. Find the following line in the new file you copied:

       device "hptmv"...
      

      Right below that line, add this line:

       device  "hptmv6"   #HighPoint RocketRAID 222x
      

   3. For amd64 targets, edit /usr/src/sys/conf/files.amd64 and append the following:

       hptmv6_lib.o optional    hptmv6  \
           dependency  "$S/dev/hptmv6/amd64-elf.hptmv6_lib.o.uu" \
           compile-with    "uudecode < $S/dev/hptmv6/amd64-elf.hptmv6_lib.o.uu" \
           no-implicit-rule
      
       dev/hptmv6/os_bsd.c      optional        hptmv6
       dev/hptmv6/osm_bsd.c     optional        hptmv6
       dev/hptmv6/hptmv6_config.c      optional        hptmv6
      

      For i386 targets, replace amd64 with i386 in the file name and text.

6. To build the kernel module separate from the static kernel, I had to edit /usr/src/sys/modules/Makefile to add hptmv6 everywhere I found hptmv. Otherwise it’s just linked into the static kernel, and no .ko module is created.

Building a 64-bit 1TB SATA RAID file server with FreeBSD 6.0-amd64

This is an account of my varied experiences building aenea, a new server for my network whose primary feature is 1TB of SATA RAID5 storage. This experience was non-standard for a few reasons:

• Case selection was nuanced
• SuperMicro hot-swap drive cage was a hassle
• Shogun heat sink was a total farce
• Shogun heat sink almost obscures the PCI-Express slot
• HP LiteScribe CD sucks
• FreeBSD 6.0 doesn’t support the RocketRaid 2220
• Figuring out how to mod the RR222x driver to 1) build on FreeBSD 6 and, 2) cross-compile for amd64 from i386
• RR222x BIOS utility is shit; ‘background initialization’ means deferred initialization
• Without the RR222x RAID management utility, only way to trigger volume init is writing to the file system; I did this by doing a FreeBSD install. Catch is, the install doesn’t actually happen (the volume isn’t initialized yet), and you must leave the box powered on for hours until the disk lights stop flashing, indicating the init it done. Then you can reboot and do a normal install.
• Lack of floppy forced use of USB floppy drive, which is fine except it took the /dev/dc0 slot, making the array /dev/dc1, though it will be /dev/dc0 if the USB floppy isn’t present. Thus, have to unplug floppy after hptmv6.ko kernel module is loaded.
• After install, copy hptmv6.ko to /boot/kernel and modify /boot/defaults/loader.conf by adding this line:

  hptmv6_load="YES"
  

• Had to add

  interface "em0" {
      send host-name="aenaea";
  }
  

  to /etc/dhclient.conf, as FreeBSD is the only OS I’ve used that doesn’t automatically send its hostname to a DHCP server.

• RAID management tools come only in 32-bit version. From the FreeBSD-amd64 list it seems you can get i386 compatibility if you build from source, which obviously I will do.
• The array suddently went ‘Critical’ on me, with disk 3 (1-based) showing up as ‘Degraded’. Of course, no docs. Now the array is spinning like crazy; my hope is that it’s repairing the degraded disk. Without management tools, I can’t know. I’m wary of building from source with the array at Critical; not only will it be slow, but it can only prolong the recovery process.
• Once the array got back to ‘Normal’, I ran a make buildworld, but the disk IO stalled during the build. It’s fairly clear that, due to amd64, version 6.0, or using FreeBSD, these volumes simply won’t work.

  I’ve no choice but to slink back to a mainstream OS. I’m leaning toward Fedora Core 4, even though it’s shit as a server system. The alternatives are Red Hat Enterprise Server (not an option) and SuSE Desktop Linux (as if FC4 wasn’t lame enough).

  The make buildworld has since unstuck itself; maybe if I can get a kernel and userland with i386 support, I can run the CLI management tools and I won’t be so screwed. We’ll see. It’ll take hours to download FC4 binaries anyway, so there’s no harm in trying.

UPDATE: this is rather agonizing. FreeBSD 6.0 release works, more or less. I can’t run the i386 CLI management tool, to no surprise. I created a few symlinks to shared libraries to get it to start, only to get this:

 Nov 25 18:06:20 aenea kernel: pid 699 (hptsvr-5.3), uid 0: exited on signal 11 (core dumped)

Not surprised; not only were these tools compiled for an earlier version of FBSD, but they’re running in the i386 compatibility layer.

The problem is there are little events that naw at me, making it impossible for me to delude myself into thinking the situation is tenable. For example, getting hung up during the buildworld. Also, doing a shutdown causes kernel panics during the unmount process.

I’m going to stress-test the disks a bit more with some port building, and see how that goes.