FreeBSD 5.4-RELEASE-p5 panic

[dpk]

On Tue, 2 Aug 2005, dpk wrote:

> (Another panic I would get would follow roughly the same path except it
> would die while trying to unlock a vnode lock that the thread didn't own.
> I'll try to get this information some time, too.)

Here's the backtrace from that panic:

#0  kdb_enter (msg=0x12 <Address 0x12 out of bounds>) at ../../../kern/subr_kdb.c:266
#1  0xc033ea1f in panic (fmt=0xc04c99ff "lockmgr: thread %p, not %s %p unlocking")
    at ../../../kern/kern_shutdown.c:550
#2  0xc0333181 in lockmgr (lkp=0xc61f5e14, flags=6, interlkp=0x1000000, td=0x0)
    at ../../../kern/kern_lock.c:419
#3  0xc038b08b in vop_stdunlock (ap=0x12) at ../../../kern/vfs_default.c:295
#4  0xc038af3b in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:157
#5  0xc03010bb in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118
#6  0xc0301648 in spec_write (ap=0xeb858a94) at vnode_if.h:1044
#7  0xc03010bb in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118
#8  0xc0452ecd in vnode_pager_generic_putpages (vp=0xc61f5d68, m=0xeb858bf0, bytecount=4096,
    flags=0, rtvals=0xeb858b70) at vnode_if.h:432
#9  0xc038b7e2 in vop_stdputpages (ap=0x12) at ../../../kern/vfs_default.c:650
#10 0xc038af3b in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:157
#11 0xc03010bb in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118
#12 0xc0452c6a in vnode_pager_putpages (object=0xc085e7bc, m=0x12, count=18, sync=0, rtvals=0x12)
    at vnode_if.h:1357
#13 0xc044a603 in vm_pageout_flush (mc=0xeb858bf0, count=1, flags=0) at vm_pager.h:147
#14 0xc044a52d in vm_pageout_clean (m=0x0) at ../../../vm/vm_pageout.c:347
#15 0xc044b3df in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:996
#16 0xc044c162 in vm_pageout () at ../../../vm/vm_pageout.c:1487
#17 0xc032911d in fork_exit (callout=0xc044be50 <vm_pageout>, arg=0x0, frame=0xeb858d48)
    at ../../../kern/kern_fork.c:791
#18 0xc0474fcc in fork_trampoline () at ../../../i386/i386/exception.s:209

Again, vm_pageout_clean is being called with a NULL argument, and
eventually the spec_vnoperate function is called with a NULL (the other
panic, ufs_vnoperate was called with a NULL).

These couple of panics are relatively easy to reproduce on demand.

Interestingly (I think), vm_pageout_flush's m argument was the same with
each panic: 0xeb858bf0 .

That is decimal 3,951,397,872 . When you boot these servers without PAE
enabled, the "real memory" is 3,757,965,312. I think this indicates that
the page vnode_pager_generic_putpages is dealing with is within the "PAE"
range (I don't know exactly how to describe that). This could be a total
long shot, but I think it's unlikely that both panics would have something
like that in common without it being a bug of some sort.

If there's somewhere else I should be sending these please let me know.