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

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

 




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. (Pr

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

[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