Compiling rr64x driver for linux kernel 3.1, 3.2, 3.3 and 3.4

Finally, got the kernel module rr64x (for my HighPoint RocketRaid 644 card) to compile under Fedora 16. Here were my steps:

[updated 2012-01-28: No change required to compile for 3.2]

[updated 2012-03-27: No change required to compile for 3.3]

[updated 2012-06-09: No changes required to compile for 3.4]

How I compiled the rr64x module for linux 3.1:

  • Unpack rr64x-linux-src-v1.0-100113-1722.tar.gz from HighPoint
  • Edit “rr64x-linux-src-v1.0/osm/linux/osm_linux.c”:
 < static int hpt_queuecommand_lck (Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 > static int hpt_queuecommand (Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 < #ifdef DEF_SCSI_QCMD
 <   DEF_SCSI_QCMD(hpt_queuecommand)
 < #else
 <   #define hpt_queuecommand hpt_queuecommand_lck
 < #endif
  • Edit “rr64x-linux-src-v1.0/osm/linux/osm_linux.h”:
 < #include <linux/kconfig.h>
 > #include <linux/config.h>
  • Compile and install by running “make KERNEL_VER=2.6 install”
[root@jalla linux]# make KERNEL_VER=2.6
 make[1]: Entering directory `/usr/src/kernels/3.1.2-1.fc16.x86_64'
 CC [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/os_linux.o
 CC [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/osm_linux.o
 CC [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/div64.o
 CC [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/hptinfo.o
 CC [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/config.o
 LD [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/rr64x.o
 Building modules, stage 2.
 MODPOST 1 modules
 WARNING: could not find /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/.him_magni.o.cmd for /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/him_magni.o
 CC      /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/rr64x.mod.o
 LD [M]  /root/rr64x/rr64x-linux-src-v1.0_working/product/rr64x/linux/.build/rr64x.ko
 make[1]: Leaving directory `/usr/src/kernels/3.1.2-1.fc16.x86_64'
  • “modprobe rr64x” and voila, it works. Sweet!

Prior to steps above, I had the following errors:

Wrong kernel version (from “make”):

../../../inc/linux/Makefile.def:85: *** Only kernel 2.4/2.6 is supported but you use 2.1.  Stop.

Missing linux/config.h (from “make KERNEL_VER=2.6”):

make[1]: Entering directory `/usr/src/kernels/3.1.2-1.fc16.x86_64'
 CC [M]  /root/rr64x/rr64x-linux-src-v1.0/product/rr64x/linux/.build/os_linux.o
 In file included from /root/rr64x/rr64x-linux-src-v1.0/product/rr64x/linux/.build/os_linux.c:6:0:
 /root/rr64x/rr64x-linux-src-v1.0/osm/linux/osm_linux.h:12:26: fatal error: linux/config.h: No such file or directory
 compilation terminated.
 make[2]: *** [/root/rr64x/rr64x-linux-src-v1.0/product/rr64x/linux/.build/os_linux.o] Error 1
 make[1]: *** [_module_/root/rr64x/rr64x-linux-src-v1.0/product/rr64x/linux/.build] Error 2
 make[1]: Leaving directory `/usr/src/kernels/3.1.2-1.fc16.x86_64'
 make: *** [rr64x.ko] Error 2

Please leave a comment if you found this information useful!! Thanks!


13 Responses to “Compiling rr64x driver for linux kernel 3.1, 3.2, 3.3 and 3.4”

  1. adam Says:

    Hey I’m trying to follow along with this but when you say edit the files could you make it more clear as to what the original line was and what the new line is supposed to say it is hard to follow this otherwise.

  2. Guy Says:

    I am having similar errors with the RR622. All I can find is documentation for some of the header files no longer existing after kernel 2.6.16. On your edits, what is the significance of the notations? I don’t appear to have the same function names and defines in the RR62X source files.

  3. Guy Says:

    I am very close now. osm_linux.h needs to have the entire ifdef precompiler directive removed regarding the incuding of linux/config.h, no biggie. Then you get an error regarding the number of arguments made to blkdev_get, which tracking this to the kernel source now requires 3 arguments, vice the two in the driver in osm_linux.c, the last of which is appears to be a null pointer from what I can get out of the kernel headers. For the life of me I don’t know what this is supposed to be to. I tried to use a simple null to this argument however, it wouldn’t compile. I substituted the number 0 as the argument and it compiles fine and appears to install. When using modprobe to install the driver however, a panic occurs, which I can provide if necessary. I am currently running the 3.3 kernel as the 3.4 kernel has other issues. Any hints you can provide to what this third argument must be would be greatly appreciated.

  4. Guy Says:

    Oh, just as added info, the driver actually appears to trigger the device to work somewhat. The drives spin up, the unit goes through its self test phases, all 8 drive lights come alive. The webgui is usable to accomplish drive and raid maintenance. However the raid isn’t made available to the Linux OS.

  5. Guy Says:

    My bad it wasn’t a null pointer, it is a void *holder argument, just found something which I hope helps me figure this out.

    • digitus2001 Says:

      Guy: Sorry, I have only played with the 644 driver and card, not touched the 622 and only on Fedora 15/16/17. Also, I generally never like the raid software/firmware on these cheap raid cards/chipsets, so I re-flashed my 644 with the “non-raid” bios. This causes my boot to be much faster and all the disks to be presented individually to Linux. I then use normal software raid (md) to create a raid array. There might be some performance loss (dont think so but not tested) but I think the flexibility of not having the raid locked to the RocketRaid 644 is gold. E.g. I can easily move the disks to another machine and controller and keep all the data.

      • Guy Says:

        The original firmware allows the same circumstance to happen. The RAID information is written to the disks as well as the card, so you could move the disks to any RAID controller (or any disks to the raid set) and it “should” pick up the same configuration, but then again, it might “have” to be another RR6XX card to read it. Many of the RAID cards today have this capability. I haven’t played with the 644 cards yet, are they slow to boot? I know it takes about 30 seconds for the firmware to spin up the drives and present the RAID to the OS, but this isn’t usually a hindrance to me as I don’t use them for my boot drives.

  6. Guy Says:

    I’ll keep trying to solve this issue, just can’t seem to find the holder value the kernel is expecting.

  7. Guy Says:

    I managed to catch HighPoint’s attention with a trouble ticket for this. Look on their website for updated drivers this week, you may see an update to all of their drivers for the post 2.6.16 kernels.

  8. Guy Says:

    The new drivers they sent to me work fine on the
    kernels. They make install correctly and even update the initrd to come up on boot. Now to dig through the source to understand the new code.

    • digitus2001 Says:

      Very nice! Do they also now use “dracut -f ” as well, so the initrd is named correctly?

      • Guy Says:

        dracut, yes, -f, no. They may have some issues surrounding that, but with a clean install or new kernel, it should fire and update the initrd. Funny you asked, of the three kernels, the 3.3.7, which I had been working on for a while, didn’t fire the call to dracut on this install, however, an earlier trial updated initrd, and it works with the new mod.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s