On 9 Aug, Alexander Kabaev wrote: > On Tue, Aug 09, 2005 at 10:33:12PM +0200, Thierry Herbelot wrote: >> Hello, >> >> I'm seeing the above panic on two machines (SMP BP6 and a notebook) with >> recent -Current (certainly "heisenbug" : the same kernel runs happily on the >> notebook). >> The panic log on the SMP machine follows. >> >> TfH > <SKIP> > > Hi, > > could you try an patch below? > > Index: vfs_subr.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v > retrieving revision 1.638 > diff -u -r1.638 vfs_subr.c > --- vfs_subr.c 6 Aug 2005 01:42:03 -0000 1.638 > +++ vfs_subr.c 9 Aug 2005 23:51:44 -0000 > _at__at_ -2333,10 +2333,8 _at__at_ > /* > * Don't vgonel if we're already doomed. > */ > - if (vp->v_iflag & VI_DOOMED) { > - VI_UNLOCK(vp); > + if (vp->v_iflag & VI_DOOMED) > return; > - } > vp->v_iflag |= VI_DOOMED; > /* > * Check to see if the vnode is in use. If so, we have to call I also noticed this inconsistency in vgonel() a couple hours ago and made exactly the same change in my local source. No problems so far, but I suspect this bug is difficult to trigger. It's been present in the code for a couple of months. The same problem is present in RELENG_6, so this fix is probably a MFC candidate for 6.0.Received on Wed Aug 10 2005 - 04:11:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:41 UTC