From owner-freebsd-current  Thu Oct  3 06:49:43 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id GAA27835
          for current-outgoing; Thu, 3 Oct 1996 06:49:43 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA27827;
          Thu, 3 Oct 1996 06:49:35 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id XAA16899; Thu, 3 Oct 1996 23:47:42 +1000
Date: Thu, 3 Oct 1996 23:47:42 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199610031347.XAA16899@godzilla.zeta.org.au>
To: dfr@render.com, julian@freefall.freebsd.org
Subject: Re: HELP!! kernel deadlock found..
Cc: current@freefall.freebsd.org
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>It looks as if N+2 is attempting to perform a pathname lookup while it has
>a locked vnode.

I usually "solve" ufslk2 hangs by rebooting.  There was one longstanding
reproducible one that seems to be fixed now.  The following script is
supposed to exercise a bug in rename() for ufs, but the system usually
used to hang on ufslk2.  I saw the bug once and hangs many times in 20+
hours of testing.  Today I've seen the bug twice and no hangs in 4 hours
of testing.
---
#!/bin/sh
a=/tmp/foo.now
b=/tmp/foo.prev
while true
do
        for n in 1 2 3 4 5 6 7 8 9 0
        do
                (mv $a $b ; touch $a) &
        done
        wait
done
---

>> if anyone knows how to examine an arbitrary process stacktrace
>> I'd like to hear about it.......

The proc struct contains a pointer to the pcb and the pcb contains the
call-saved registers for savectx() including %esp and %ebp.  %ebp is
actually for savectx()'s caller.

BTW, what should happen if the pcb (or other data that you're looking
at) is paged out?  Interrupts are disabled, so disk i/o may not work.
I'm fixing ddb so that interrupts are always disabled, and gdb-remote
should probably keep them disabled too.  I think pagefaults should be
fatal if interrupts are disabled (or spl >= splbio).  The debugger's
setjmp handler will make them non fatal (just like when you attempt
to access an unmappable address).

>I wanted to do this with DDB once and I think I was stumped by the kernel
>stack being in the u-area which is mapped to the same place for each
>process.  Since the process I wanted to backtrace was not curproc, I
>couldn't see its stack :-(.

There should be a ddb function for this.  ddb functions are now easy to
add :-).

Bruce