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.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
