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