On Mon, 19 Jul 2004, Stephen M. Jones wrote:

> db{0}> trace
> cpu_Debugger() at netbsd:cpu_Debugger+0x4
> panic() at netbsd:panic+0x1e8
> console_restart() at netbsd:console_restart+0x74
> XentRestart() at netbsd:XentRestart+0x90
> --- console restart (from ipl 3) ---
> wakeup() at netbsd:wakeup+0x68

  From examination of wakeup(), it looks like CPU0 was probably trying to
aquire scheck_lock.  I'd guess that CPU1 currently has sched_lock and may
be trying to acquire another lock that CPU0 currently holds.  Without
LOCKDEBUG, it may be rather difficult to tell much more.  It might be
possible to dig back through the stack trace to see if there's a place
where CPU0 has a lock on something.

  A quick check would be to do and 'x/x sched_lock' and 'x/x kernel_lock'
at the DDB prompt.  I think a non-zero value indicates the lock is
currently held.

> nfsrv_wakenfsd() at netbsd:nfsrv_wakenfsd+0xc8
> nfsrv_rcv() at netbsd:nfsrv_rcv+0x138
> sowakeup() at netbsd:sowakeup+0xd8
> udp4_sendup() at netbsd:udp4_sendup+0x14c
> udp4_realinput() at netbsd:udp4_realinput+0x2ac
> udp_input() at netbsd:udp_input+0x2ec
> ip_input() at netbsd:ip_input+0xaa4
> ipintr() at netbsd:ipintr+0xa0
> netintr() at netbsd:netintr+0x88
> softintr_dispatch() at netbsd:softintr_dispatch+0x194
> exception_return() at netbsd:exception_return+0x7c
> --- root of call graph ---

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA