I run a 486 with a PCI bus. The onboard IDE interface does not support DMA. In order to get better disk performance, I added a Promise based Maxtor Ultra ATA/100 PCI Adapter Card. I hooked the only drive in the system to it's primary master. The BIOS on the card detects the HDD on boot and the drive boots LILO succesfully. The kernel boots fine, but init has a conniption when trying to start up and freezes. I can boot using the init=/bin/bash and get a shell. I fixed the aliases in lilo.conf, and fstab. I reran LILO. I can fsck the disk and mount it rw. The system is unstable though and tends to crash with disk access. The hdparm -t tool is successful at causing a "Kernel Panic: Aiee, Killing interrupt handler! In interrupt handler - not syncing"

I tried setting hdparm -c3 -m16 -X66 -d1 and the machine seems ok. This is only UDMA 2, though. This drive, and IBM 60GXP, claims to support UDMA5. If I set UDMA5 with -X69 the machine crashes predictably with hdparm -t. I tried UDMA4 with -X68 with -c1 and it had trouble, but did not crash. I tried UDMA4 with -c3 and it seemed ok.

The man page for hdparm suggests that you need to set the controller card to the proper mode before you change modes with the -X option. It does not, however, suggest what command can do this!

Does anyone know why init is not working, if hdparm can fix this, how to set the card on boot so that init can run (if this is a fix), and why I can't use UDMA5, or how to use it properly.

Thank you! I'm using the stock RedHat 7.1 kernel. Other boards claim kernel 2.4 has native support for UDMA 100.

You are running a 486 CPU so you probably have an old motherboard. You might want to try the Promise Ultra 33 PCI adapter. You can get one on ebay. I had a similar problem with a Pentium CPU on a motherboard built before 1998. I couldn't get Windows98 to run with the Promise Ultra-66 adapter, but the Promise Ultra-33 adapter worked. I suspect that the problem was that the PCI bus was earlier than version 2.1. You may have the same problem. If any UDMA card works, it will be the Ultra-33.

Also, not all Promise Ultra-100 cards work with RedHat 7.1 or higher (as of today, Jan-2-01). To the best of my knowledge, Group 1 cards are OK and Group 2 cards are NOT. You can see the "PDC" number stamped on the Promise chip on the adapter card.

Group 1
Promise Ultra33 or PDC20246
Promise Ultra66 or PDC20262
Promise Ultra100 or PDC20265
Promise Ultra100 or PDC20267

Group 2
Promise Ultra100 TX2 or PDC20268
Promise ULtra133 or PDC20269 ???

Where can I find info like that on which Promise chips are supported??

I don't understand why not having PCI rev 2.1 would foul things up. Couldn't the card run in a lower mode? Also, running the hdd in PIO mode seems to allow it to run fine so that would seem to negate the possibility of this problem. How can I check which revision I have?

Could making a new kernel with Promise controller support in it help? I don't know if the stock kernel has this, so I'm trying. Also, I'm compiling it with ide=reverse support so that it will use the add on card as the primary controller (/dev/hda & hdb).

Does anyone know what mdma mode is? While on the motherboard's controller, my hdd runs in mdma2.

Here's a little more clarification. In my Win98 Ultra-66 vs Ultra-33 problem mentioned above, a slower mode (probably PIO) worked for the Ultra-66 card, but none of the UDMA modes worked. I believe that MDMA stands for multi-word DMA and that MDMA-2 is the same rate as PIO-4. I believe that all of the MDMA rates are slower than the slowest UDMA rate, which is Ultra-33.

The following website may help in identifying your motherboard chipset, and whether it is PCI 2.1 compliant or not. The website has links to several motherboard manufacturers. http://www.motherboards.org/chipsets.html Note that most manufacturers' websites seem to have little info about their older motherboards.

The easiest place to look for a list of RedHat-supported Promise cards is on the box of a RedHat 7.1 retail package. I think that's about the limit of my knowledge - good luck!

I haven't gone over the differences between rev 2.0 and rev 2.1, but I know that it there are enough of them to break things. For example, I can't put my newer PCI 2.1 SCSI accellerator cards (Adaptec and ATTO brands) into any of my older PCI 2.0 Macintosh boxes. I've found documentation on the manufacturers' web sites explicitly stating that installing their 2.1 cards in a 2.0 bus is asking for trouble.

make sure your hard drives are still setup correctly. if you were booting from hda1, make sure that physical hard drive is still hda1 in the dmesg... the ide controller card may have thrown drive/device labeling off.

Well, my last trick was a newly compiled kernel. I double checked drive reassignments, fstab, everything! I got the machine to boot fine, but it was never stable in any mode. I tried booting using the motherboard's controller and rolling a new kernel. I compiled in the Promise driver (the card had a PDC20267 chip). I also compiled it with the option for detecting add-on controllers first. This made my new kernel see the primary master on the add-on card as hda. I booted with my new kernel and everything worked. The drive was listed as hda while plugged into my add-on controller.

Unfortunately, I still got kernel panics and often times linux would spew huge amounts of number sequences in parenthases on the screen. I don't know what these were, but they seemed related to disk access.
My only conclusion is that, as brian_eye said, the brand spanking new controller needed PCI rev 2.1 and my MB just didn't have it. This motherboard is a Biostar 486 board. The PCI bus had just come out at the time of this board and no one was even sure if it or VLB was going to fly. It has 3 PCI ports and 4-5 ISA ports. There's no way it obeys newer revisions due to its age.

I've decided to return the controller and drop this project. The disk seems to be able to run fast enough to max out my network bandwidth (10Mb/s network) and I'll soon have a newer mb to play with anyway. Instead I am going to concentrate on learning to make Linux talk Appletalk for now.

Thanks for your help all, esp. brian_eye. I would have never thought of that problem!