On 15-Aug-01 Michael Lucas wrote:
> On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote:
>> To help localize this problem, could you please try this same thing on
>> a kernel without devfs?  The dump you sent me did not look like a
>> Vinum bug, as I said in my reply.
> Sorry, it happens on a non-devfs kernel as well.  Since it doesn't
> appear to be a Vinum bug, I'm taking the liberty of sending the whole
> thing to -current.  (I sent my first dump to Greg in particular, since
> a Vinum command triggered whatever this is.)

> Script started on Wed Aug 15 17:57:48 2001
> magpire/var/crash;file /boot/kernel/vinum.ko 
> /boot/kernel/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1
> (FreeBSD), not stripped
> magpire/var/crash;file kernel.debug.nodevfs 
> kernel.debug.nodevfs: ELF 32-bit LSB executable, Intel 80386, version 1
> (FreeBSD), dynamically linked (uses shared libs), not stripped
> magpire/var/crash;gdb -k kernel.debug.nodevfs vmcore.3 
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...
> IdlePTD 4284416
> initial pcb at 34b860
> panicstr: bremfree: bp 0xcc2a1ae4 not locked

Unfortunately this is the panic message from later on during the syncing disks
stage, not the real panic. :(

>#15 0xc01f0783 in witness_destroy (lock=0xc1ec4e68) at

This is the real problem:

        STAILQ_REMOVE(&all_locks, lock, lock_object, lo_list);
        lock->lo_flags &= ~LO_INITIALIZED;

It panics in the STAILQ_REMOVE().  I've seen this a couple of times but have no
idea how that list pointer is getting corrupted.  My guess is that a mutex is
being destroyed twice or something dumb like that; however, I'm not sure how.
The LO_INITIALIZED flags and checks are supposed to catch that case.  I suppose
there is a chance we could preempt in between the LO_INITIALIZED check and the
actual removal and then free it and get in trouble that way.  Hmm.  Try moving
the mtx_lock of &all_mtx before the check for LO_INITIALIZED and see if you can
get a different panic.  It may be a bug in the ucred stuff.  (At least several
other panics of this type have been the result of crfree's.)


John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to