Getting UDMA66 to Work

Table of Contents:
I - Original Content from Grrlfox
II - Notes from Kedar P..
III - Update (5/11/00) from tai4ji2x

Original NHF Content
Posted By: Grrlfox

Kernel patching always sounded totally esoteric, and more than a little scary to me. I mean, downloading beta software and patching it into my kernel source tree? It wasn't long ago that just the thought of compiling a new kernel was frightening to me.

I kept listening to the hardware types at work (I'm a Windoze programmer) talking about the ways they were spicing up their systems. They were talking about how the latest thing in IDE drives is UDMA/ATA66. The interface features burst data transfers of up to 66 MB/second, and, if you use a third party controller card, allows you to have up to 8 IDE devices in a single computer. UltraDMA also allows IDE drives to be larger, up to 128 GB. I was almost out of hard drive space, so my Christmas present to myself was a new IBM 13.5 gig, 7200 rpm, 2 MB cache UDMA/ATA66 drive. Of course, I couldn't see myself putting that drive onto on of my old-fashioned PCI IDE ports. Instead, I went out and ordered a Promise controller card.

It uses a PCI slot, but I still had one of those empty, so I plugged in the card, and ran the BIOS installer, and Windoze NT saw the drive immediately. So, of course, I rebooted into Linux to partition it, since most of it was to be used for new Linux partitions. You know the next part of the story - new hardware + Linux is NOT a match made in heaven.

There's no native support for these third party cards, at least not in the 2.2.x kernels. The 2.3.x development kernels probably have support for UDMA though, as with help from TxRogue, on the Efnet channel #linuxnewbie, I found a kernel patch for such support on the kernel.org website.

So what IS a kernel patch, anyway? It doesn't sound like anything you'd want to do to the core program that keeps your computer running. When I came across the idea, I immediately thought of those lil patches that my mom used to iron onto the knees of my jeans. Not what I want to do to my operating system. But...this WAS on the kernel home site...so I got smart, and typed man patch at the command prompt. (Ok, so the command prompt was in an Eterm session...picky, picky, picky). You can see what I read on the Web, at this page.

Anyway, there are patches for both 2.2.13 and 2.2.14 kernels at the kernel.org site, in both bz2 and gz format (bz2 is smaller :). NOTE that you MUST have the kernel source already installed on your file system for the patch to do you any good! If you haven't gotten it already, check here for the latest version. By the way, if you scroll all the way down, you'll see that there are lots of patches, these for patching the kernel source from one version to the next. That was one of the things that convinced me that patching my kernel probably wasn't as scary as it sounded.

Once you've downloaded the patch to your system, decompress it in your linux directory (/usr/src/linux is typical). Then do this command (learned from reading this web page): patch -p1 ‹ ide.2.2.13.19991102.patch (unless you're patching 2.2.14, of course!).

Now you need to recompile your kernel. In the BLOCK DEVICE section of the configuration, choose the option to Use DMA by default when available, and Generic PCI bus-master DMA support. Pick the hardware that looks like it matches your card, finish your kernel configuration, and compile the kernel (make dep, make bzImage, make modules, make modules_install) and reboot. You should be able to access the hard drives connected to your card! I'm happily using mine, and enjoying how much faster files load now. Even better - I'm over my fear of patching :)

Note:
Sent in by: Kedar P.

You don't need to patch your hardware (third party controller from promise technologies), if you are running kernel 2.2.x. For 2.0.x I have no idea. I run 30 such boxes in our office, all of them identical, and using this Promise Technologies controller. All I had to do was give extra command line arguments to the kernel at boot time. To figure out the command line arguments, but with a linux boot/rescue floppy. When you reach the command prompt, do a
cat /proc/pci

You should see something like this in the output produced by this command, in addition to other junk.

Now Note down the values on those lines beginning with I/O, call them a, b, c, d (which in my case are 0x1400, 0x10f4, 0x10f8, 0x10f0). Ignore "e" (0x1080).

Then give the following command line argument to your kernel on the "lilo" prompt.

lilo: linux ide2=a,b+2 ide3=c,d+2

Which in my case is:
lilo: linux ide2=0x1400,0x10f6 ide3=0x10f8,0x10f2

You should see the drive through linux after that. To avoid having to type that command line arguments to kernel everytime, you can configure lilo to automatically do this for you. Just consult lilo doc about "append" option.

---------------------

Update (5/11/00):
From tai4ji2x

It turns out that the last document (henceforth referred to as the HPT366-howto) which Grrlfox referenced above [in the current NHF], has been updated recently and contains most of the info that I would have written up for this NHF separately. The main problem with many of the other current or popular docs as of 5/11/00 (such as this NHF prior to my added comments, and also somewhat the official Ultra-DMA mini-HOWTO at linuxdoc.org), was that they didn't adequately deal with the "chicken-and-egg" problem of trying to install Linux on an UltraDMA controller that isn't supported in an unpatched, stock kernel...

Pay special attention to the bulleted sections (of the HPT366-howto) titled "Enabling HPT366 without UDMA/66 support" and "Installing Linux to an UDMA/66 drive", as it provides the details to solving the chicken-and-egg problem. (NOTE: It probably still requires that the distribution you are trying to install contains kernel version 2.2.x or higher though - Debian 2.1, from what I've heard, cannot follow this procedure, because its kernel is v2.0.x.) The information, which although is for the HPT366 controller (found both onboard on the Abit BP6 and BE6-II motherboards, and offboard on several generic Ultra-DMA66 PCI controllers such as from Iwill), also applies to the Promise Technologies Ultra66 controller as well.

Note however, that for some GUI-based install routines such as that of Red Hat 6.x, exiting to a virtual console requires Ctrl-Alt-F2, not just Alt-F2. This is a new development that I've noticed isn't included yet in every UltraDMA-related Linux doc I've come across so far...

Also, quoting from the second-to-last paragraph in the section titled "Enabling HPT366 without UDMA/66 support" in the HPT366-howto:

in some cases you might need to supply the IRQ numbers to the kernel as well. If that is the case, then change the kernel boot time option in the example above to "ide2=0xb000,0xb402,11 ide3=0xbc00,0xc002,11" where the 3rd arguement is the IRQ number reported by /proc/pci

The problem manifests itself in the fact that despite adding the "ide2=" and "ide3=" parameters to the "append=" line in lilo.conf, the controllers (especially the secondary, ide3) sometimes still won't be detected properly at bootup. The error will not occur if you enter in the parameters manually at the LILO "boot:" prompt, but most people will opt to include that info in their lilo.conf until they patch their kernel with the patches from Andre Hedrick. Thus, it is best to also include the IRQ information, as noted in the above quote.

Another interesting thing that the HPT366-howto describes is a method for obtaining the memory I/O addresses using Win9x, as opposed to going through the process of switching to a virtual console during install and checking out /proc/pci. I have devised an easier Win9x routine (unfortunately, I wish I could have the time to write it out more clearly):

Right-click "My Computer", then click Properties, then go to the Device Manager tab. Next, (as long as "View devices by type" is the current viewing option) go to SCSI controllers -> and double-click on the Promise Technologies controller (or another similar controller such as the HPT366). Under the "Resources" tab, there should be five "Input/Output Range" entries with settings in the format "E400 - DC07" (or other similar numbers). Use the first four Input/Output Range entries' first four numbers. Read that last sentence again, it's confusing. As in the above example, the number you want is "E400", and not "DC07". Then use these in the same manner and in the same order, respectively, as mentioned in the cat /proc/pci method described by Kedar.

In conclusion, this should help people in installing their Linux systems on hard drives connected to non-standard UDMA66 controllers such as the Promise Ultra66 and HighPoint HPT366-based ones. They should still subsequently patch their kernels with Andre Hedrick's IDE patches however, as described by Grrlfox, above. (For their specific kernel versions, of course... as of this writing, a patch for the current stable version, 2.2.15, is available.) In order to get full Ultra-DMA66 support and transfer speeds, patching the kernel is required!

Hope this helps,
Xenon (tai4ji2x on Linuxnewbie boards)