Lately I have been seeing lots of panics.  I upgraded to 1.5.1_BETA2 in
the hopes of clearing it up but the problem persists.  I created a
debugging kernel and now I have a core dump of a crashed kernel.  Can
someone help me figure it out?  I assume that the first thing I need to
do is figure out which program is running when this happens.  Can someone
suggest what sort of tools I can use on this core file?

Here are a few things that I have tried.  First, I did a backtrace.

#0  0xc023035b in i386_features ()
#1  0x249a000 in ?? ()
#2  0xc01f34e7 in cpu_reboot (howto=256, bootstr=0x0)
    at ../../../../arch/i386/i386/machdep.c:1174
#3  0xc012b3f3 in panic () at ../../../../kern/subr_prf.c:240
#4  0xc01fa255 in trap (frame={tf_es = -1071382512, tf_ds = 16, 
      tf_edi = -1068730504, tf_esi = -1077936128, tf_ebp = -901603856, 
      tf_ebx = -1067269056, tf_edx = -901179532, tf_ecx = 114581504, 
      tf_eax = 32868, tf_trapno = 6, tf_err = 0, tf_eip = -1071674810, 
      tf_cs = 8, tf_eflags = 66050, tf_esp = 0, tf_ss = 4, 
      tf_vm86_es = -1068730504, tf_vm86_ds = -1067269056, tf_vm86_fs = 3, 
      tf_vm86_gs = 0}) at ../../../../arch/i386/i386/trap.c:308
#5  0xc0100c23 in calltrap ()
#6  0xc01ef761 in uvn_flush (uobj=0xca2c5a18, start=0, stop=0, flags=20)
    at machine/pmap.h:478
#7  0xc01ef1d0 in uvn_detach (uobj=0xca2c5a18)
    at ../../../../uvm/uvm_vnode.c:413
#8  0xc01e7028 in uvm_unmap_detach (first_entry=0xca75ff48, amap_unref_flags=0)
    at ../../../../uvm/uvm_map.c:1129
#9  0xc01e63db in uvm_unmap (map=0xc9f770bc, start=0, end=3217022976)
    at ../../../../uvm/uvm_map_i.h:183
#10 0xc01eeed4 in uvm_deallocate (map=0xc9f770bc, start=0, size=3217022976)
    at ../../../../uvm/uvm_user.c:66
#11 0xc011badf in exit1 (p=0xca5b79a4, rv=0)
    at ../../../../kern/kern_exit.c:206
#12 0xc011b99c in sys_exit (p=0xca5b79a4, v=0xca429f88, retval=0xca429f80)
    at ../../../../kern/kern_exit.c:138
#13 0xc01fa72b in syscall (frame={tf_es = 31, tf_ds = 31, 
      tf_edi = -1077944336, tf_esi = -1077946292, tf_ebp = -1077946452, 
      tf_ebx = 5, tf_edx = 0, tf_ecx = 134938687, tf_eax = 1, tf_trapno = 3, 
      tf_err = 2, tf_eip = 134814467, tf_cs = 23, tf_eflags = 646, 
      tf_esp = -1077946564, tf_ss = 31, tf_vm86_es = 0, tf_vm86_ds = 0, 
      tf_vm86_fs = 0, tf_vm86_gs = 0}) at ../../../../arch/i386/i386/trap.c:767
#14 0xc0100c83 in syscall1 ()
can not access 0xbfbfd7ac, invalid translation (invalid PDE)
can not access 0xbfbfd7ac, invalid translation (invalid PDE)
Cannot access memory at address 0xbfbfd7ac.

I then pulled a ps -axl from the core.  I found 89 processes for http which
I thought was a little excessive for the time that the crash happened but
I assume that NetBSD should be able to handle that.  What was odd, however,
was the 9 lines like this.

65534 10420    0   2  30  0 -1772748   0 -        Z    ??  0:00.00 (httpd)

Is it just because they are zombies that I see the negative number for VSZ?
It doesn't look like that on the running system.

-- 
D'Arcy J.M. Cain <darcy@givex.com>                    http://www.givex.com/
+1 416 350 9660 Ext: 225