From owner-freebsd-scsi Sun May 18 12:45:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08815 for freebsd-scsi-outgoing; Sun, 18 May 1997 12:45:30 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08810; Sun, 18 May 1997 12:45:29 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id NAA19645; Sun, 18 May 1997 13:45:24 -0600 (MDT) Message-Id: <199705181945.NAA19645@pluto.plutotech.com> To: Nick Esborn cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: RELENG-22 fatal trap 18 In-reply-to: Your message of "Sun, 18 May 1997 11:31:18 PDT." Date: Sun, 18 May 1997 14:43:45 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Fatal trap 18: integer divide fault while in kernel mode >instruction pointer = 0x8:0xf01b5eea This doesn't look at all like a SCSI problem. SCSI problems usually show up as transaction timeouts, not integer divide panics. The fact that your filesystem needs to be fscked at boot is simply a consequence of the crash. The next thing for you to do is to find out what routine the instruction pointer is in. Doing an "nm /kernel | sort" will do that for you. The next step is to put DDB into your kernel (options DDB + *full* kernel rebuild) so you can provide a stack trace the next time it happens. My gut feeling is that you shouldn't be overclocking your P6 and that this is the cause of your problem. Overclocking issues are usually very load dependant, and different versions of FreeBSD have different memory/cache load characteristics. You might want to try putting it back to where it's supposed to be to see if this clears up your problem. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================