>Juergen Weiss weiss@uni-mainz.de writes:
>
>In NetBSD-1.3_BETA I observed the following panic while
>running top:
>
>#2  0xfffffc0000262b34 in panic () at ../../../../kern/subr_prf.c:150
>#3  0xfffffc0000391fbc in trap () at ../../../../arch/alpha/alpha/trap.c:527
>#4  0xfffffc0000230428 in XentMM ()
>    at ../../../../arch/alpha/alpha/locore.s:377
>#5  0xfffffc000025e680 in sysctl_doproc ()
>    at ../../../../kern/kern_sysctl.c:649
>#6  0xfffffc000025db64 in kern_sysctl () at ../../../../kern/kern_sysctl.c:270
>#7  0xfffffc000025d744 in sys___sysctl () at ../../../../kern/kern_sysctl.c:159
>#8  0xfffffc0000392200 in syscall () at ../../../../arch/alpha/alpha/trap.c:641
>#9  0xfffffc0000230488 in XentSys ()
>
>The allproc.lh_first, p_list.le_next chain is undamaged,
>but the variable p contains
>
>p p
>$6 = (struct proc *) 0xdeadbeefdeadbeef


Be careful: as a general rule, NetBSD/Alpha does not yet support
examining stack objects and intermediate frames in kernel crash dumps.

-----------
Ross Harvey ross@teraflop.com