From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 21:31: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 C26A137B401 for ; Sat, 2 Aug 2003 21:31:03 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC64D43F85 for ; Sat, 2 Aug 2003 21:31:02 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1049 invoked from network); 3 Aug 2003 04:31:02 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 3 Aug 2003 04:31:02 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h734V09s010964; Sun, 3 Aug 2003 00:31:00 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <63725642.1059732523@[10.122.7.157]> Date: Sun, 03 Aug 2003 00:31:21 -0400 (EDT) From: John Baldwin To: Eivind Olsen cc: grog@FreeBSD.org cc: current@freebsd.org Subject: RE: 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: Sun, 03 Aug 2003 04:31:04 -0000 On 01-Aug-2003 Eivind Olsen wrote: > 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 this might be a bug in vinum, but I'm not sure. Either the buf passed in to DEV_STRATEGY() in launch_requests() has a NULL device (which I doubt), or the dev_t device has a NULL si_drv2 field. Greg (cc'd) might be able to help out further. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/