On Wed, 6 Feb 2002, sgimips NetBSD list wrote:

> Since I last build a miniroot for sgimips, last December,
> I am now having the following problem:
>
> mod80 (355)# newfs /dev/rvnd0a
> /dev/rvnd0a:    163840 sectors in 5120 cylinders of 1 tracks, 32 sectors
>         80.0MB in 6 cyl groups (917 c/g, 14.33MB/g, 3328 i/g)
> super-block backups (for fsck -b #) at:
>      32,  29376,  58720,  88064, 117408, 146752,
> cg 0: bad magic number
>
> I can't determine if this is a vnd problem or a newfs issue.
> I can mount a disk image previously (December) build and it fsck's fine.
>
> Anyone recognise a problem I'm overlooking?

Scott,

It isn't a nice one to track down.  I have seen it several times on other
ports.

Possible causes:
 - Disklabel synchronization issues (a VND device gets a disk label)
 - Cache coherency issues when using unaligned DMA in the wdsc driver.
    thorpej-mips-cache merge occured in november so shouldn't be a cause.
    wdsc.c rewrite also occured in Novemeber, so unlikely cause.
 - chrtoblktbl[] entries not correct (for the vnd major number)
 - RAW Disk transfers are not transfering the full byte count.

The chrtoblktbl[] entries look to be OK, so other things to check:

First, check to see if it behaves on a block device (more than likely it
will)

Then check that it is a local disk issue by using nfs or mfs based
filesystems (using the rvnd device)

Using a binary approach build a kernel tree to determine the date that the
problem started.   This is a time consuming task, but often more
production than hit-and-miss techniques.   Start by going back to December
kernel when you think it worked.....


-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org