Re: panic: lock (sleep mutex) vnode interlock not locked

On  9 Aug, 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
> 
> #ident /usr/src/sys/kern/vfs_subr.c
> /usr/src/sys/kern/vfs_subr.c:
>      $FreeBSD: src/sys/kern/vfs_subr.c,v 1.638 2005/08/06 01:42:03 ssouhlal 
> Exp $
> 
> FreeBSD 7.0-CURRENT #758: Tue Aug  9 20:18:36 CEST 2005
>     XX_at_YYY:/usr/obj/usr/src/sys/GENERIC
> WARNING: WITNESS option enabled, expect reduced performance.
> MPTable: <OEM00000 PROD00000000>
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
>   
> Features=0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
> real memory  = 100663296 (96 MB)
> avail memory = 88850432 (84 MB)
> ....
> panic: lock (sleep mutex) vnode interlock not locked 
> _at_ /usr/src/sys/kern/vfs_subr.c:2117
> cpuid = 1
> KDB: enter: panic
> [thread pid 49 tid 100039 ]
> Stopped at      kdb_enter+0x2b: nop
> db> where
> Tracing pid 49 tid 100039 td 0xc12a4900
> kdb_enter(c0859e9d) at kdb_enter+0x2b
> panic(c085de0d,c08753f9,c085d79a,c0862e0e,845) at panic+0x127
> witness_unlock(c1850d3c,8,c0862e0e,845) at witness_unlock+0xbc
> _mtx_unlock_flags(c1850d3c,0,c0862e0e,845,c1850cc0) at _mtx_unlock_flags+0x5b
> vdropl(c1850cc0,7,c12a4900,c09076c0,c1850cc0) at vdropl+0x5e
> vlrureclaim(c1471800,c12a4900,c12a3830,c068412c,c12a3830) at vlrureclaim+0x1fd
> vnlru_proc(0,c7228d38,0,c068412c,0) at vnlru_proc+0x18b
> fork_exit(c068412c,0,c7228d38) at fork_exit+0xa0
> fork_trampoline() at fork_trampoline+0x8

Something similar here on a UP Athlon machine.  It happened while I was
using cvs to update /usr/ports from my nfs-mounted CVS repo.  The line
number in vfs_subr.c is different, and in my case the panic happened in
vdestroy(), which is called by vdropl(), instead of directly in
vdropl().

panic: lock (sleep mutex) vnode interlock not locked _at_ /usr/src/sys/kern/vfs_su
br.c:750
KDB: enter: panic
[thread pid 46 tid 100042 ]
Stopped at      kdb_enter+0x2b: nop     
db> tr
Tracing pid 46 tid 100042 td 0xc2370480
kdb_enter(c08674e2) at kdb_enter+0x2b
panic(c086b19a,c0883023,c086ab33,c0870150,2ee) at panic+0xbb
witness_unlock(c5b9a07c,8,c0870150,2ee) at witness_unlock+0xbc
_mtx_unlock_flags(c5b9a07c,0,c0870150,2ee) at _mtx_unlock_flags+0x5b
vdestroy(c5b9a000,c5b9a000,e5054cec,c069111d,c5b9a000) at vdestroy+0x1b5
vdropl(c5b9a000,7,c2370480,c0914ce0,c5b9a000) at vdropl+0x3e
vlrureclaim(c25b1000,c2370480,c243b000,c06912f8,c243b000) at vlrureclaim+0x1fd
vnlru_proc(0,e5054d38,0,c06912f8,0) at vnlru_proc+0x18b
fork_exit(c06912f8,0,e5054d38) at fork_exit+0xa0
fork_trampoline() at fork_trampoline+0x8