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