I do this within my lilo.conf (adjust numbers for your disk!)
===========/etc/lilo.conf=======================
disk=/dev/ataraid/d0
# BIOS knows /dev/ataraid/d0 as C:
bios=0x80
# These strange numbers are from "fdisk -lu /dev/ataraid/d0"
sectors=63
heads=255
cylinders=1216
partition=/dev/ataraid/d0p1
start=63
prompt
timeout=50
default=linux
boot=/dev/ataraid/d0
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear
image=/boot/vmlinuz
label=linux
read-only
root=/dev/ataraid/d0p3
====================================
----- Original Message -----
From: HOFMANN_ROBERT_G_III@xxxxxxxxx
To: ataraid-list@xxxxxxxxxx
Sent: Monday, April 22, 2002 3:07 PM
Subject: Re: I'm out of things to try, maybe someone can help ...
It's not a lilo issue. Booting off of the Gentoo Linux CD, which is
kernel 2.4.19 and has ataraid/pdcraid compiled as a module. I run a
modprobe ataraid followed by modprobe pdcraid and the arrays on the
ST34321A disks are never detected. Inserting some debug code and
recompiling the modules showed me that the pdcraid.o modules is not
reading the right block for the superblock information (although I
haven't found the right block yet either.) The problem is that Linux
detects the drives with geometry 8894/15/63, which is what pdcraid uses
to calculate superblock location. The Promise firmware on the other
hand, detects the drives with geometry 523/255/63. Both geometries are
listed as valid on the seagate support page. I just can't figure out
how to force the drive into one mode or the other.
Bob
Murty Rompalli <murty@xxxxxxxxxxxxxxx>
Sent by: ataraid-list-admin@xxxxxxxxxx
04/19/2002 02:55 PM
Please respond to ataraid-list
To: ataraid-list@xxxxxxxxxx
cc:
Subject: Re: I'm out of things to try, maybe someone can
help ...
which version of lilo are you using
On Wed, 17 Apr 2002 HOFMANN_ROBERT_G_III@xxxxxxxxx wrote:
> I've been wrestling with getting ataraid support for promise fasttrak
> controllers working on my linux server. Here is a (somewhat) brief
> summary of my setup, findings, and problems:
>
> The system:
> MSI 694D Rev 1 motherboard, Dual Celeron 400's (FSB at 75MHz
to
> overclock at 450), 1GB SDRAM, Onboard PDC20265 with Full Raid BIOS
> Onboard ATA100 - IDE1: ATAPI CD-ROM (/dev/hda)
> Onboard ATA100 - IDE2 : MASTER - WDC21600 1.6GB (/dev/hdc);
> SLAVE - WDC21600 1.6GB (/dev/hdd)
> Onboard PDC20265 - IDE3: MASTER - ST34321A Seagate Medalist
Pro
> 4.3GB (/dev/hde)
> Onboard PDC20265 - IDE4: MASTER - ST34321A Seagate Medalist
Pro
> 4.3GB (/dev/hdg)
> Offboard PDC20262(1) - IDE1: MASTER - ST51270A Seagate
Medalist SL
> 1.2GB (/dev/hdi)
> Offboard PDC20262(1) - IDE2: MASTER - ST51270A Seagate
Medalist SL
> 1.2GB (/dev/hdk)
> Offboard PDC20262(2) - IDE1: MASTER - ST34321A Seagate
Medalist
> Pro 4.3GB (/dev/hdm)
> Offboard PDC20262(2) - IDE2: MASTER - ST34321A Seagate
Medalist
> Pro 4.3GB (/dev/hdo)
>
> The problem:
>
> After a lot of fiddling around to get the system happy with all the
add-on
> cards and everything, I am able to configure arrays on the Fasttrak100
> BIOS and on the Fasttrak66 BIOS successfully. However, the ataraid
and
> pdcraid modules do not see all of the arrays. Specifically, they fail
to
> recognize arrays on the Medalist Pro 4.3GB disks. At first I thought
it
> might be a version problem or distribution problem or even a problem
with
> the controllers. I tried several distros (currently I am running a
base
> Gentoo distribution with the 2.4.19 kernel) and I have confirmed that
the
> arrays appear properly in the DOS environment. I can access and
partition
> all of the drives individually from linux fdisk. In the Gentoo linux
> distro, the two 1.6GB Western Digital drives are even discovered as an
> array on ATA100 IDE2 after they are RAID prepped by the fasttrak
> controller.
>
> What I have found:
>
> After ruling out many configuration issues, I got my hands dirty and
> started looking at the pdcraid.c code. I have added some printk
> statements in the probedisk and superblock load routines to try to get
a
> handle on what is going on. It appears that the fasttrak controller,
at
> boot, is treating the ST34321 drives as having geometry C=523, H=255,
> S=63. This is the physical CHS geometry listed on Seagate's support
> page. Linux, on the other hand, is seeing the LBA geometry of C=8894,
> H=15, S=63, which among other things results in a different overall
sector
> count. The end result is that the pdcraid computation of where to
locate
> the superblock (first sector of last cylinder) is coming up with a
> different value than the promise BIOS, and hence is not locating the
> superblock. This also explains another problem I had been having
which
> was that the BIOS RAID configuration would disappear upon successful
> installation of a linux distro. (Promise puts the superblock in a
location
> where Linux thinks data can go).
>
> What I am looking for:
>
> Ideally, I'd like to figure out how to get the Promise controller to
> address the disks in LBA mode, as this results in a slightly larger
> capacity. Looking at things from the other side, I have not yet tried
> forcing the geometry via kernel boot parameters and may do so this
> evening, although that is not my preferred long term solution.
>
> Has anyone seen a similar situation before? Any ideas?
>
> Thanks,
> Bob
>
_______________________________________________
Ataraid-list@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/ataraid-list
