From owner-freebsd-ppc@FreeBSD.ORG Mon Jul 19 14:49:40 2004 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D12916A4CE; Mon, 19 Jul 2004 14:49:40 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32D4243D31; Mon, 19 Jul 2004 14:49:40 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i6JEndWg021990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2004 10:49:39 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i6JEnXGL043035; Mon, 19 Jul 2004 10:49:33 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16635.57213.872393.12719@grasshopper.cs.duke.edu> Date: Mon, 19 Jul 2004 10:49:33 -0400 (EDT) To: Peter Grehan In-Reply-To: <40FB1C83.3010800@freebsd.org> References: <16634.61745.306200.480570@grasshopper.cs.duke.edu> <40FB1C83.3010800@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-ppc@freebsd.org Subject: Re: kernel not bootable today? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2004 14:49:40 -0000 Peter Grehan writes: > > OK boot > > Kernel entry at 0x12ab48 ... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > > > DEFAULT CATCH!, code=900 at %SRR0: 0000a840 %SRR1: 00083000 > > ok > > 0 > > > That's before interrupt vectors have been setup, or it would > have dropped into ddb. Is this repeatable ? Yes.. it seems to be. I run a kernel without WITNESS, INVARIANTS, INVARIANTS_SUPPORT, or KTR. That will crash like this every time. If I add back INVARIANTS_SUPPORT and INVARIANTS, it works fine. Eg: diff TEST.worked TEST 64,65d63 < options INVARIANTS #Enable calls of extra sanity checking < options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS Maybe there is some cache-sync or something that is required at load time, but which is missing, and INVARIANTS slows down the MI code enough to mask the bug? Now that I've found the option that kills it, I'll see if I can do a binary CVS search for a "good" vs "bad" kernel date. If there's a better way, please let me know.. From the SRM console on alpha, you could at least get the PC at the time of the fault. Is this possible with openfirmware? Drew