From owner-freebsd-stable@FreeBSD.ORG Sun Oct 8 16:33:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 089FA16A403 for ; Sun, 8 Oct 2006 16:33:08 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7101E43D4C for ; Sun, 8 Oct 2006 16:33:06 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id k98GWrCI055745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Oct 2006 18:32:54 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <200609212301.24257.mail@maxlor.com> References: <200609192217.44712.mail@maxlor.com> <200609212301.24257.mail@maxlor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BFB7742-7064-49DB-BD1A-45512CF37F06@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sun, 8 Oct 2006 18:32:52 +0200 To: Benjamin Lutz X-Mailer: Apple Mail (2.752.2) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic on boot (how to debug?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2006 16:33:08 -0000 Am 21.09.2006 um 23:01 schrieb Benjamin Lutz: > By sheer luck I figured out how to get into DDB though :), so I can > now > provide a backtrace. > > Fatal trap 18: integer divide fault while in kernel mode ... > --- trap 0x12, rip = 0xffffffff801c02d5, rsp = > 0xffffffff80864a80, rbp = > 0xffffffff80864ad0 --- > ata_raid_promise_read_meta() at ata_raid_promise_read_meta+0x95 > ata_raid_read_metadata() at ata_raid_read_metadata+0x2f4 Reading through ata_raid_promise_read_meta(), it's not clear to me how that trap would get triggered, but you might want to boot verbose to see how far into ata_raid_promise_read_meta() it gets. It seems to me that there is something on your disk that almost looks like a RAID metadata sector, and the driver getting confused by it. Also, try not compiling ataraid into the kernel to see if that avoids the trap. HTH, Stefan -- Stefan Bethke Fon +49 170 346 0140