Subject: Re: Problems with NetBSD 1.3 Solaris2 original filesystem
To: Brian Buhrow <buhrow@cats.ucsc.edu>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: port-sparc
Date: 01/08/1998 15:08:30
On Jan 7, Brian Buhrow wrote
> 	Hello Manuel.  I threw in the towell and newfsed  up a new filesystem.
> Since we had been having problems with filesystem coruption under Solaris,
> I thought perhaps there was some lurking under the covers that was biting
> us.  For some reason, I thought SCSIVERBOSE was turned on in generic
> kernels,

It is for i386. It think it should for other ports too.

> but I believe the problem may be taht we're trying to read beyond
> the end of the disk.

This is what I think too, but I'd prefer to be sure ...

> Do you know of a problem whereby Seagate disks report
> more sectors than they actually have?  This is a ST19171N.  For good
> measure, I reduced the cylinder count by a couplle and re-labeled the disk
> before I newfsed.

The driver check the blocks numbers of the transfert against the
partition size and offset before sending the command if the partition
is not the raw partition. So if you used the 'c' partition of your disk,
no checks are done in the driver.
I have a seagate drive here (a 2gig barracuda), but I partitioned it,
and all partitions begins and end on cylinders boundaries (as reported
by the disk) so I actually use a little less sectors than the drive report.

> Is there a case where data corruption on the disk could
> cause the system to try and read beyond the end of the filesystem?

There is, if you are using the raw ('c') partition. Otherwise checks are done
in the driver before sending the command.

> Also,
> does NetBSD/Sparc know how to detect hardware errors, i.e. parity errors in
> the same way SunOS and Solaris do on Sun equipment?  My thought here is
> taht there may have been some memory error which went undetected and which
> caused faulty data to be written to disk at some point.
> 

I think NetBSD should detect it, with maybe less informational message.
But I think the kernel should get an NMI and print something about it.
Perhaps one of the NetBSD/sparc guru could confirm this ?

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--