Processes hung in 'inode' state ...

[Marc G. Fournier]

Can't this time, since we had to reboot (else alot of pissed off
postgresql.org users *grin*) ... but will add that to my debugging for
next time through ... the fun part is catching the system while its only
one of the VMs that is stuck and not the whole server :(

On Mon, 23 Jun 2003, David Schultz wrote:

> On Mon, Jun 23, 2003, Marc G. Fournier wrote:
> >
> > Not sure what all to do, but doing a 'gdb -k kernel.debug /dev/mem', a
> > backtrack on one of the processes shows ... server has been up 12 days
> > now, and running a June 8th kernel ...
> >
> > #0  0x20f4f0 in ?? ()
> > (kgdb) proc 67258
> > (kgdb) bt
> > #0  mi_switch () at machine/globals.h:119
> > #1  0x8014a1f9 in tsleep (ident=0x8a3d2200, priority=8, wmesg=0x80263d4a "inode", timo=0) at /usr/src/sys/kern/kern_synch.c:479
> > #2  0x80141507 in acquire (lkp=0x8a3d2200, extflags=16777280, wanted=1536) at /usr/src/sys/kern/kern_lock.c:147
> > #3  0x8014179c in lockmgr (lkp=0x8a3d2200, flags=16973826, interlkp=0xbdc27b6c, p=0xc26fa9c0) at /usr/src/sys/kern/kern_lock.c:355
>
> Ooh, a deadlock.  I'm guessing unionfs is responsible again.  ;-)
> Can you type in the following?
>
> 	print *(struct lock *)0x8a3d2200
>
> Then get a backtrace of the process with pid equal to lk_lockholder.
>