I just upgraded my i386 Tinderbox machine last night, and a package
build triggered this panic.  I've been using this machine for Tinderbox
for a year or so now, and this is the first such panic I received.  The
disk in question is 61% used, and I am building locally using loopback
NFS mounts.

FreeBSD fugu.marcuscom.com 7.0-CURRENT FreeBSD 7.0-CURRENT #12: Sun Sep
30 02:14:27 EDT 2007
gnome@fugu.marcuscom.com:/space2/obj/usr/src/sys/FUGU  i386

I was previously running a kernel from September 19 without any
problems.

dev =3D ad6s1e, block =3D 22287592, fs =3D /space
panic: ffs_blkfree: freeing free block
cpuid =3D 0
KDB: enter: panic
Physical memory: 2038 MB
Dumping 351 MB: 336 320 304 288 272 256 240 224 208 192 176 160 144 128
112 96 80 64 48 32 16

#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0xc045ed89 in db_fncall (dummy1=3D-236168880, dummy2=3D0, dummy3=3D70,=20
    dummy4=3D0xf1ec58bc "=F0\022F=C0") at /usr/src/sys/ddb/db_command.c:486
#2  0xc045f2f5 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:401
#3  0xc0460d25 in db_trap (type=3D3, code=3D0)
at /usr/src/sys/ddb/db_main.c:222
#4  0xc0595316 in kdb_trap (type=3D3, code=3D0, tf=3D0xf1ec5a64)
    at /usr/src/sys/kern/subr_kdb.c:502
#5  0xc072d32f in trap (frame=3D0xf1ec5a64)
at /usr/src/sys/i386/i386/trap.c:621
#6  0xc07131fb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc0595492 in kdb_enter (msg=3D0xc07706ef "panic") at cpufunc.h:60
#8  0xc056dda4 in panic (fmt=3D0xc077ee64 "ffs_blkfree: freeing free
block")
    at /usr/src/sys/kern/kern_shutdown.c:547
#9  0xc0698954 in ffs_blkfree (ump=3D0xc5140300, fs=3D0xc508a800,=20
    devvp=3D0xc5167990, bno=3D22287592, size=3D16384, inum=3D5566594)
    at /usr/src/sys/ufs/ffs/ffs_alloc.c:1893
#10 0xc06ac318 in indir_trunc (freeblks=3D0xcf6d4000, dbn=3D89113600,
level=3D0,=20
    lbn=3D12, countp=3D0xf1ec5c4c)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2896
#11 0xc06ac5f7 in handle_workitem_freeblocks (freeblks=3D0xcf6d4000,
flags=3D0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2746
#12 0xc06add8e in process_worklist_item (mp=3D0xc512029c, flags=3DVariable
"flags" is not available.
)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:963
#13 0xc06aedb2 in softdep_process_worklist (mp=3D0xc512029c, full=3D0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:847
#14 0xc06b127d in softdep_flush ()
at /usr/src/sys/ufs/ffs/ffs_softdep.c:758
#15 0xc054d5b9 in fork_exit (callout=3D0xc06b0e00 <softdep_flush>,
arg=3D0x0,=20
    frame=3D0xf1ec5d38) at /usr/src/sys/kern/kern_fork.c:796
#16 0xc0713270 in fork_trampoline ()
at /usr/src/sys/i386/i386/exception.s:205

I know this backtrace may not be all that useful since this is an
assertion, but I wanted to know if there was perhaps a recent change
that went in that could account for this new behavior.  Thanks.

Joe

--=20
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome