From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 01:08:03 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A91637B401 for ; Fri, 1 Aug 2003 01:08:03 -0700 (PDT) Received: from vimes.aminor.no (vimes.aminor.no [213.187.177.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B745143FD7 for ; Fri, 1 Aug 2003 01:08:01 -0700 (PDT) (envelope-from eivind@aminor.no) Received: from localhost (localhost [127.0.0.1]) by vimes.aminor.no (Postfix) with ESMTP id 6EAD578E8C for ; Fri, 1 Aug 2003 10:08:08 +0200 (CEST) Received: from vimes.aminor.no ([127.0.0.1]) by localhost (vimes.eivind [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01347-04 for ; Fri, 1 Aug 2003 10:07:56 +0200 (CEST) Received: from [10.122.7.157] (nextra-3-244.nextra.no [148.122.3.244]) by vimes.aminor.no (Postfix) with ESMTP id 912EA78E85 for ; Fri, 1 Aug 2003 10:07:56 +0200 (CEST) Date: Fri, 01 Aug 2003 10:08:43 +0200 From: Eivind Olsen To: current@freebsd.org Message-ID: <63725642.1059732523@[10.122.7.157]> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at aminor.no Subject: Fatal trap 12 under RELENG_5_1, anyone who can help? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2003 08:08:03 -0000 Hello. My FreeBSD RELENG_5_1 server (cvsupped 4 days ago) seems to have problems - it crashes from time to time (approx. once a day). I've rebuilt the kernel with debug-symbols and enabled the debugger and caught a crash tonight: Here's what I had on screen (I also ran "show reg" and "trace"): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02e8139 stack pointer = 0x10:0xcfbf684c frame pointer = 0x10:0xcfbf6880 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 46373 (ctl_cyrusdb) kernel: type 12 trap, code=0 Stopped at g_dev_strategy+0x29: movl %eax,0x14(%ebx) db> show reg cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xf7255200 ecx 0 edx 0 ebx 0 esp 0xcfbf684c ebp 0xcfbf6880 esi 0xc201e824 edi 0xc2044900 eip 0xc02e8139 g_dev_strategy+0x29 efl 0x10286 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0xffff0ff0 dr5 0x400 dr6 0xffff0ff0 dr7 0x400 g_dev_strategy+0x29: movl %eax,0x14(%ebx) db> trace g_dev_strategy(c201e824,c2152800,0,cfbf68d0,c2098eca) at g_dev_strategy+0x29 launch_requests(c2e16e80,0,10000,ffffffff,43) at launch_requests+0x448 vinumstart(c5ad9da8,0,c243aab0,cfbf694c,c02e5bc6) at vinumstart+0x2b2 vinumstrategy(c5ad9da8,0,c0b79490,40,0) at vinumstrategy+0xa6 spec_xstrategy(c215b7fc,c5ad9da8,cfbf6968,c02e4f18,cfbf6994) at spec_xstrategy+0x306 spec_specstrategy(cfbf6994,cfbf69b0,c044f7ad,cfbf6994,0) at spec_specstrategy+0x1b spec_vnoperate(cfbf6994,0,c0b79490,f,c5ad9da8) at spec_vnoperate+0x18 ufs_strategy(cfbf69d8,cfbf6a0c,c0359a87,cfbf69d8,1) at ufs_strategy+0xdd ufs_vnoperate(cfbf69d8,1,c0504f45,35e,cfbf69f8) at ufs_vnoperate+0x18 bwrite(c5ad9da8,cfbf6a5c,c0361aca,c5ad9da8,c5ad9ed8) at bwrite+0x3a7 bawrite(c5ad9da8,c5ad9ed8,10,3c6,20020080) at bawrite+0x1c cluster_wbuild(c302c000,4000,4c,0,4) at cluster_wbuild+0x6ba cluster_write(c5afaf08,84cf9c,0,51,c2f82300) at cluster_write+0x571 ffs_write(cfbf6be0,c1fb97f8,c243aab0,227,c2158600) at ffs_wrie+0x5ff vn_write(c1fb97f8,cfbf6c7c,c2f82300,0,c243aab0) at vn_write+0x192 write(c243aab0,cfbf6d10,c0518514,3fb,3) at write+0x69 syscall(2f,2f,2f,0,807e000) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c, ebp = 0xbfbfec38 --- db> I _think_ I've managed to type it all in correctly. No crash dump was made (I have dumpdev="/dev/ad0s1b" in /etc/rc.conf) - are there anything else I need to do to get it to crashdump to that device? Should I have given any other commands to the internal debugger to find more information? The kernel I'm running is really GENERIC with a few small changes: vimes# diff VIMES /usr/src/sys/i386/conf/GENERIC 25c25 < ident trisha --- > ident GENERIC 30c30 < makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols --- > #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols 62c62 < options DDB #Enable the kernel debugger --- > #options DDB #Enable the kernel debugger 266,269d265 < # This option is a subset of the IPFILTER option. < options IPFILTER #ipfilter support < options IPFILTER_LOG #ipfilter logging < options IPFILTER_DEFAULT_BLOCK #block all packets by default vimes# So, can anyone help me out here? Are there anything else I should have done to find more information? Any other commands to give to the kernel debugger? Any way of making the crashdump happen next time I see a kernel trap like this? -- Eivind Olsen eivind@aminor.no