Re: I'm out of things to try, maybe someone can help ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux RAID]     [Linux Device Mapper]     [Linux IDE]     [Linux SCSI]     [Kernel]     [Linux Books]     [Linux Admin]     [GFS]     [RPM]     [Yosemite Campgrounds]     [AMD 64]

  Powered by Linux