> Our SPARC running NetBSD has been crashing, reliably, every night.

in a word: "cool!"  8-)

> the
> deepest few frames on the stack are always
> 
> #0  0xf8006a50 in snapshot ()
> #1  0xf8006a58 in snapshot ()
> #2  0xf80b8478 in boot ()
> #3  0xf801fdc0 in panic ()
> #4  0xf80bf12c in mem_access_fault ()
> #5  0xf8005358 in trapbase ()
> #6  0xf8039560 in vgone ()
> #7  0xf80383bc in getnewvnode ()

my one big question is: what's the address that's causing the fault?

to get a crash in vclean() (As you said was happening, in a later
paragraph), there are very few things that can be wrong.  mostly, 'vp'
would have to be a bogus pointer...

off the cuff, my guess would be that it's 0xdeadbeef, and that it's
getting set that way by somebody holding a reference to it, after it
was free()'d, though i dunno why it'd be freed...  I've actually got a
bit of circumstantial evidence to back up that guess, but nothing
solid...

umm, it's my understanding that sparc kernels not only do crash dumps,
but those crash dumps work well with 'gdb -k'...  you might look into
that for further debugging...  (i'm actually quite interested in
looking into it myself, but i can't replicate it here; time to read
some code!  8-)

>I
>suspect the fifth mount (the one of type null) is related, largely
>because the trouble started about the same time I added it.

This sounds like a reasonable suspicion.  The pathnames aren't related
to the vnode that is causing the problem...  The miscfs file systems
look like a good place for _me_ to start reading, though i'm not
entirely sure they're the problem.



chris
p.s. good to see that _some_ people take heed of our opinions on
what constitutes a good bug report...  8-)