In message <[EMAIL PROTECTED]>, Vallo Kallaste writes:
>The same kernel compiled for purposes of smbfs debugging crashed
>again. I had X, make -j2 running and no smbfs mounts. For what it's
>worth, the system did hang hard (no interrupts) some minutes before
>the aforementioned crash and I had to reboot by hand.
>From the trace, we are recursing on ufs_inactive() because it needs
to grab and release a vnode reference from within vput()->VOP_INACTIVE(),
so the second vput() causes another call to VOP_INACTIVE. This looks
like something the VINACTIVE patch I posted a while ago would fix:
http://www.maths.tcd.ie/~iedowse/FreeBSD/vinactive.diff
(Sorry, I haven't updated it, so it probably needs manual merging)
See also the comments by Don Lewis on this list ("Re: nfs_inactive()
bug? -> panic: lockmgr:").
Kirk, is this vput() recursion expected? If so, something like the
patch above should ensure that the second vput() does not call
VOP_INACTIVE() again.
Ian
>(kgdb) where
>#0 doadump () at ../../../kern/kern_shutdown.c:223
>#1 0xc0236e8a in boot (howto=260) at ../../../kern/kern_shutdown.c:355
>#2 0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
>#3 0xc027e982 in bwrite (bp=0xce3e92dc) at ../../../kern/vfs_bio.c:796
>#4 0xc027f039 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
>#5 0xc033b16f in ffs_fsync (ap=0xd795958c) at ../../../ufs/ffs/ffs_vnops.c:23
>6
>#6 0xc033a499 in ffs_sync (mp=0xc4057400, waitfor=2, cred=0xc13c3e80,
> td=0xc0436be0) at vnode_if.h:612
>#7 0xc02939e8 in sync (td=0xc0436be0, uap=0x0)
> at ../../../kern/vfs_syscalls.c:130
>#8 0xc0236a6b in boot (howto=256) at ../../../kern/kern_shutdown.c:264
>#9 0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
>#10 0xc0228f80 in lockmgr (lkp=0xc45fd43c, flags=65543, interlkp=0xc45fd378,
> td=0xc3eb70d0) at ../../../kern/kern_lock.c:433
>#11 0xc028640c in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:279
>#12 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
>#13 0xc0290d6a in vclean (vp=0xc45fd378, flags=8, td=0xc3eb70d0)
> at vnode_if.h:990
>#14 0xc029142a in vgonel (vp=0xc45fd378, td=0x0)
> at ../../../kern/vfs_subr.c:2665
>#15 0xc0291310 in vrecycle (vp=0xc45fd378, inter_lkp=0x0, td=0x0)
> at ../../../kern/vfs_subr.c:2620
>#16 0xc03413fc in ufs_inactive (ap=0x0) at ../../../ufs/ufs/ufs_inode.c:133
>#17 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
>#18 0xc0290420 in vput (vp=0xc45fd378) at vnode_if.h:930
>#19 0xc033212d in handle_workitem_freeblocks (freeblks=0xc4d07500, flags=0)
> at ../../../ufs/ffs/ffs_softdep.c:2494
>#20 0xc03315f4 in softdep_setup_freeblocks (ip=0xc4d4c500, length=0,
> flags=2048) at ../../../ufs/ffs/ffs_softdep.c:2077
>---Type <return> to continue, or q <return> to quit---
>#21 0xc0327938 in ffs_truncate (vp=0xc45fd378, length=0, flags=3072, cred=0x0,
>
> td=0xc3eb70d0) at ../../../ufs/ffs/ffs_inode.c:271
>#22 0xc03412c8 in ufs_inactive (ap=0x0) at ../../../ufs/ufs/ufs_inode.c:100
>#23 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
>#24 0xc0290420 in vput (vp=0xc45fd378) at vnode_if.h:930
>#25 0xc03336c2 in handle_workitem_remove (dirrem=0xc4567140, xp=0x0)
> at ../../../ufs/ffs/ffs_softdep.c:3324
>#26 0xc032f0ed in process_worklist_item (matchmnt=0x0, flags=0)
> at ../../../ufs/ffs/ffs_softdep.c:727
>#27 0xc032eea0 in softdep_process_worklist (matchmnt=0x0)
> at ../../../ufs/ffs/ffs_softdep.c:624
>#28 0xc028f411 in sched_sync () at ../../../kern/vfs_subr.c:1739
>#29 0xc0222e14 in fork_exit (callout=0xc028f010 <sched_sync>, arg=0x0,
> frame=0x0) at ../../../kern/kern_fork.c:860
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
