Promise ATA RAID broken
David Rhodus
drhodus at machdep.com
Thu Jul 15 11:30:55 PDT 2004
I've heard of this happing before from a few people. I'm getting one of
these same cards in the lab tomorrow so I can take a look at this. From
my understanding so far the card should work fine out of RAID mode.
-DR
Paul Herman wrote:
Hey fellas,
I updated a machine to 1.0-RELEASE (was running a March 12th system)
and the ATA RAID array is no longer readable.
It seems that while probing, the kernel ATA driver inadvertently
resets the RAID configuration. Because the array is also my '/' file
system, I'm dropped into the mountprompt> and the only thing to do is
to reboot. After reboot you need to enter the Promise BIOS and
reconfigure the damaged arrays.
When it works, the dmesg looks like:
atapci0: <Promise TX2 ATA133 controller> port
0xcc00-0xcc0f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07
mem 0xe2040000-0xe2043fff irq 11 at device 10.0 on pci2
[...]
ar0: 1907348MB <ATA RAID1 array> [46544/255/63] status: READY subdisks:
0 READY ad4: 239372MB <Maxtor 6Y250P0> [486344/16/63] at
ata2-master UDMA133
1 READY ad6: 239372MB <Maxtor 4A250J0> [486344/16/63] at
ata3-master UDMA133
I couldn't save the broken dmesg, but I'm pretty sure it says the same
thing as above, but then afterward it says:
ar0: ERROR - array broken
My guess is that somehow the configuration gets changed and then the
change gets picked up by ata-raid.c:ar_config_changed() which reports
it broken. Some sort of bad reset? Anyone out there with any ATA foo?
A kernel from March 12th (the only other one I have available) works
fine. I'm unfortunately not in a position to do a binary date search
on the offending change.
-Paul.
More information about the Bugs
mailing list