Trying RedHat 7.2

My first attempt at installing RedHat resulted in the captured error message you see here. This occured shortly after booting to the CD and loading the kernel. This struck me as odd since the AK31 installed with no errors. After doing some research, I found that the problem is due to some "bad" code in the ide-pci.c driver and relates directly to the Highpoint 372 RAID controller. With the HPT controller disabled, the installation will run flawlessly. However, not being able to use the shiny new RAID chip wouldn't be much fun. After reading through Highpoint's website, I found a Linux driver and install disk for the controller. But, this left two obstacles. One was the fact that the driver required a BIOS update to the RAID controller. Since the BIOS ROM for the HPT 372 is embedded into the system BIOS for the motherboard, you cannot simply use the flash utility from Highpoint. The BIOS version shipped on our review-motherboard was newer than the version on Shuttle's site but still contained V2.0 of the HPT BIOS. The Linux driver required V2.1 or higher. To perform the update, I used a utility called CBROM, which was obtained from BIOSMods.com. CBROM allows you to insert and remove PCI ROM's from a system BIOS image. I copied the BIOS to an image with AwardFlash, then extracted the old HPT ROM and replaced it with the new version from Highpoint using the CBROM utility. I then reflashed the system BIOS and had V2.2 of the HPT BIOS running with no problems. While this method worked for me, be warned, modifying your BIOS can render your motherboard useless if done improperly. It's not my fault if you toast that brand new motherboard!

With the Highpoint update out of the way, I was back to installing RedHat. Highpoint offers their Linux driver for a variety of Linux distributions. The dowload for the RedHat distribution contains a boot disk with a modified kernel and a driver disk used during the start of installation. Shortly after booting with the boot disk, you will be asked for the driver disk. This installs the Highpoint driver which uses SCSI emulation to control the Highpoint controller. BTW, it is VERY important to follow the directions contained in the download. After installing the OS, you must drop to a shell and replace the RedHat installed kernel with Highpoint's hacked kernel contained on the floppy. This brings us to our second problem. The driver supplied by HPT is binary only - closed source. This means that most likely, you are not going to be able to upgrade your kernel without getting errors. The driver is loaded in an initrd RAM disk and not compiled directly into the kernel. However, an upgrade to a newer kernel will usually result in "unresolved symbol" errors. We contacted Highpoint about this and they told us that a new driver would be out by the end of this month which would allow kernel upgrades. I assume this means it will be open source but don't know for sure. Another thing about the drivers... Since Highpoint uses SCSI emulation, we would expect there to be some overhead. Performance should take a hit over using standard IDE drivers. We will prove this point later.

Following direction from Highpoint, the installation went fine. However, we were stuck at using the Linux kernel 2.4.7-10, which is the shipping kernel on RedHat 7.2. The current stable kernel is 2.4.18. I tried upgrading to 2.4.9, 2.4.17, and 2.4.18. All resulted in "kernel panics" and "unresolved symbols". If you don't know what a "kernel panic" is, you are probably having a tough time reading this article. :) In short, it's bad! Adjusting "version information" during the kernel configuration did not help either. It seems with this method of installation, we are stuck with kernel 2.4.7-10. For some of you, that may be acceptable. If you just want to tinker around with linux on a dual boot machine, then it works. Windows will dual boot in this RAID configuration with no problems. However, if you are into tweaking your Linux system, it sucks.


Why The Default Kernel Crashes

During one of many kernel compilations, I noticed that there was preliminary support for the Highpoint 370 RAID controller using the ataraid.o, hptraid.0 and hpt366.o drivers. The HPT 370 is not much different than the HPT 372 other than the 372 offers ATA-133 support. The controllers even share the same BIOS which is labeled as "Highpoint 370/372". When these drivers are loaded properly they will make devices in /dev/ataraid. In theory, if we could get the drivers loaded and change our partitions in fstab to /dev/ataraid/* instead of using /dev/sda*, it should take over the install fine. I tried several times to use these alternate drivers but the kernel would still panic at the same location. I began reading up on the ataraid driver and came upon some posts to the ataraid mailing list. One post by Gu Minging led me to the the problem.

Hi,
    I found this is caused by a programming error in hpt366.c, it uses revision id as an array index todisplay name string. However, HPT372's revision is 5 which is an outbound index! You can modify the file yourself and build a new kernel to solve it before it was modified in Linux releases.
Ming

Not knowing much about programming, I began fumbling around the hpt366.c code. I found what I thought Ming was referring to, but it did not fix the problem. I then looked at the ide-pci.c code and found the same line of code there as well. The ide-pci.o driver is the universal PCI IDE controller driver which loads before the other drivers. This is why it was crashing.

char *chipset_names[] = {"HPT366", "HPT366", "HPT368", "HPT370", "HPT370A", "HPT372"};
...
strcpy(d->name, chipset_names[class_rev]);

The part in bold indicates what is needed to be added. In essence this is what happens. The chipset names are the input into the array. They are numbered from 0 on. So before the modification, we had 0,1,2,3,4. Later in the code, when we use class_rev to call the chipset revision id, which in the HPT372's case is revision 5, the is no entry and the driver crashes. Once we add the new chipset name, chipset revision 5 is validated. I later found that that this problem has been addressed in the Alan Cox versions of 2.4.18. You can get those pimped out version of recent kernels from kernel.org under /pub/linux/kernel/people/alan. the -ac3 patch contains this code. It's always nice to find a solution after you spend hours trying to do it yourself. Such is Linux...


Getting All Of This To Work / Wasting Time

After the kernel was recompiled with this code, I made the approprite entries into fstab and re-installed lilo to point to the new RAID device. All was well until I rebooted. The kernel didn't crash, but the system was about as stable as Mike Tyson at a press conference. I got drive errors all over the place. Originally, I thought this was because of the partitions created with the Highpoint driver disk. I tried hacking the boot disk by replacing the kernel with my own version but Redhat wouldn't install to the ataraid device. This is when I discovered Gentoo linux.