Re: nb5 panic: kernel diagnostic assertion "cv_is_valid(cv)" failed: file "/usr/nbcvs/src-5/sys/kern/kern_condvar.c", line 329 (fwd)

[Andrew Doran <ad%netbsd.org@localhost>]

On Sat, Jan 24, 2009 at 01:55:25AM +0100, Hubert Feyrer wrote:
> On Thu, 22 Jan 2009, David Young wrote:
> >>PPPoE connectipn down & up on a machine that's connecting a LAN with an
> >>IPsec-encrypted GRE-Tunnel...
> >
> >We cannot take the stack trace literally:  I figure that the call
> >to sbunlock() near the bottom of greintr() has called cv_broadcast().
> >If you have a netbsd.gdb hanging around, you can extract a line
> >number:  load netbsd.gdb with gdb and type the command 'l
> >*(greintr+0xcb)'.
> 
> Here's what I get:
> 
> (gdb) l *(greintr+0xcb)
> 0xc0334f0b is in greintr (/usr/nbcvs/src-5/sys/sys/socketvar.h:478).
> 473
> 474     static inline void
> 475     sounlock(struct socket *so)
> 476     {
> 477
> 478             mutex_exit(so->so_lock);
> 479     }
> 480
> 481     #ifdef SOCKBUF_DEBUG
> 482     /*
> (gdb)
> 
> FWIW, I've seen that and similar panics with 'gre' in the mean many times.
> :-(

Are you running with LOCKDEBUG? If it spews the following then it is not
memory corruption but something killing the socket while still in use.

panic("lockdebug_lookup: uninitialized lock (lock=%p, from=%08"PRIxPTR")",
lock, where);

Andrew