"Aaron J. Grier" writes:
> On Tue, Feb 29, 2000 at 10:12:19PM +1100, matthew green wrote:
> 
> > these are the SCSI devices connected to my 3000/400:
> [SNIP]
> > yes, it has 6 scsi busses. :-)  i've not experienced any problems with
> > accessing the tape drive while the disks.  i do recall hearing that it
> > was an *old* problem, fixed many years ago, though.
> 
> Hmm...  my setup isn't quite so large:
[snip]
> /, /usr, and /var are on sd0.
> 
> I'm setting up a RAID5 on the four Conners, (thanks Greg!) but when I
> initialize the parity (with 'raidctl -i'), I get a bunch of recoverable
> read errors.  Poking at the internal state of the machine with a
> 'raidctl -s' immediately stops the read errors.  Parity also doesn't
> seem to "stick" -- IE I can configure a fresh RAID, initialize the
> serial number, initialize the parity, unconfigure the RAID, and when I
> try and configure it again, it complains that the components aren't
> clean.

Arg!  This parity not sticking is a bug, and (I believe) is entirely my fault.
In sys/sys/dev/raidframe/rf_drivers.c in the function rf_Shutdown() change:

 rf_update_component_labels(raidPtr);

to 

 rf_final_update_component_labels(raidPtr);

(and then add the prototype:

  void rf_final_update_component_labels( RF_Raid_t *);

to rf_kintf.h )

I've just checked in this fix... (In the meantime, if you do the parity 
initialization, build a filesystem, mount it, then umount it, the parity 
status should then be correct when you then unconfigure and re-configure.)

Thanks for noting this...

Later...

Greg Oster