On Fri, Jun 02, 2006 at 06:41:32PM +0200, Wilko Bulte wrote: > On Thu, Jun 01, 2006 at 11:01:07PM +0100, Robert Watson wrote.. > > > > On Thu, 1 Jun 2006, Wilko Bulte wrote: > > > > >My dual-CPU DS20 Alpha box can more or less consistently be > > >forced into a panic like: > > > > > >FreeBSD/alpha (goldrush.wbnet) (ttyd0)^ > > > > > >login: panic: lockmgr: thread 0xfffffc007d9d4a80, not exclusive lock holder > > >0xfffffc006052d260 unlocking > > >cpuid = 1 > > >KDB: enter: panic > > > > > >Trigger is a "make -j2 release". j2 seems to be needed, not seen it with > > >-j1 > > > > > >Unfortunately after printing the line with "KDB" the whole thing appears > > >to become completely catatonic :( > > > > Try putting a call to critical_enter() towards the beginning of panic(). > > Sometimes this increases the reliability of entering the debugger by > > avoiding interrupt delivery during the process of entering. If you want to > > be able to continue out, you'll need a critical_exit() at the end, but that > > generally isn't helpful for panic(). > > Jay! ANother one, and this one entered the debugger alright: > > racing pid 25497 tid 100147 td 0xfffffc004df56000 > kdb_enter() at kdb_enter+0x48 > panic() at panic+0x210 > lockmgr() at lockmgr+0x798 > vop_stdunlock() at vop_stdunlock+0x34 > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x84 > vput() at vput+0xb4 > lookup() at lookup+0xd38 > namei() at namei+0x554 > do_execve() at do_execve+0x17c > kern_execve() at kern_execve+0x160 > execve() at execve+0x60 > syscall() at syscall+0x438 > XentSys() at XentSys+0x64 > --- syscall (59, FreeBSD ELF64, execve) --- > --- user mode --- > db> > > How to proceed here? I have 0 clue on lockmgr & friends :)
Enable DEBUG_VFS_LOCKS and DEBUG_LOCKS, then use 'show lockedvnods' to find what other thread(s) is holding locks, and also trace them with 'tr <pid/tid>' Kris
pgpbyGKtoNlQX.pgp
Description: PGP signature
