From owner-freebsd-current@FreeBSD.ORG Wed May 28 17:43:42 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 25D9F37B401 for ; Wed, 28 May 2003 17:43:42 -0700 (PDT) Received: from mx.dsl.isometry.net (pc3-oxfd2-6-cust207.oxfd.cable.ntl.com [81.103.193.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9BC043F3F for ; Wed, 28 May 2003 17:43:40 -0700 (PDT) (envelope-from robin@isometry.net) Received: from isometry.net (ishadow [195.137.51.150]) by mx.dsl.isometry.net (Postfix) with ESMTP id 70628F1 for ; Thu, 29 May 2003 00:43:38 +0000 (UTC) Message-ID: <3ED557B8.2020909@isometry.net> Date: Thu, 29 May 2003 01:43:36 +0100 From: Robin Breathe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030521 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: ccd(4): Fatal trap 18: integer divide fault while in kernel mode 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: Thu, 29 May 2003 00:43:42 -0000 Caught a panic in ccd under 5.1-BETA-20030526-JPSNAP (GENERIC with unused devices disabled, zero_copy(9) and polling(4)) while rsyncing a number of ~50MB files onto a 2-disk ccd stripe (ccd0 1152 none /dev/ad4s1d /dev/ad7s1d; ...; newfs -U /dev/ccd0d). Irritatingly, the panic was only repeatable under a kernel with INVARIANTS/WITNESS disabled, and no dump device defined, but when I recompiled with them enabled, and created a large enough dump partition, it disappeared. I've been unable to repeat the panic since (in either state). Anyway, this is what we have, in case it means anything to anyone: Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xc2e4b9e2 stack pointer = 0x10:0xdf11cbac frame pointer = 0x10:0xdf11cbec 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 = 4 (g_down) kernel: type 18 trap, code=0 Stopped at ccdbuffer+0x162: idivl 0(%esi),%eax db> trace ccdbuffer(df11cc28,c63d2800,c6ae1870,0,ffd51458) at ccdbuffer+0x162 ccdstart(c63d2800,c6ae1870,1,0,aa28b000) at ccdstart+0x75 ccdstrategy(c6ae1870,0,c0392637,53,0) at ccdstrategy+0xa6 g_disk_start(c673a990,0,c0392a89,159,64) at g_disk_start+0x19e g_io_schedule_down(c21ae000,c21ae000,df11cd34,c0200d2e,0) at g_io_schedule_down+0x19c g_down_procbody(0,df11cd48,c03943dd,2f8,0) at g_down_procbody+0x28 fork_exit(c01e32f0,0,df11cd48) at fork_exit+0xae fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf11cd7c, ebp = 0 --- db> Is there anything more useful I can provide with what I have? (debug kernel compiled, but no dump to get specifics from... I'm not a gdb expert). I'll continue to try and replicate the initial panic, and get some more helpful data. - Robin -- _____________________________________________________________________ [ Robin Breathe | robin at isometry dot net | +44 1865 741800 ]