From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 27 16:51:31 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 553C916A4CE for ; Tue, 27 Jan 2004 16:51:31 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17D8E43D5F for ; Tue, 27 Jan 2004 16:51:02 -0800 (PST) (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 i0S0p15P026891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2004 19:51:01 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i0S0otV2012085; Tue, 27 Jan 2004 19:50:55 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16407.1903.816168.318651@grasshopper.cs.duke.edu> Date: Tue, 27 Jan 2004 19:50:55 -0500 (EST) To: Tom Ponsford In-Reply-To: <40143372.8090207@theriver.com> References: <4011B6F6.5040306@theriver.com> <40143372.8090207@theriver.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: Same problem, new year 2100A machine check X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 00:51:31 -0000 Tom Ponsford writes: > It DOES NOT boot: > > FreeBSD 4.xx MP kernel -machine check as it probes PCI/EISA bus Interesting. FreeBSD 4 never supported MP on alpha. > FreeBSD 5.0, 5.2 uniprocessor kernel or MP kernel--machine check as it probes Here are some things to do/try. 1) Build a kernel with ddb and get a stack trace. When the machine crashes and you land at the "db>" prompt, type 'tr' This might not be incredibly helpful because machine checks are not synchronous, but it may narrow things down a little bit. 2) Disable all but CPU0 from the SRM console. There's a bitmask you can set from SRM (I don't remember off the top of my head what it is, but its probably set to 0xfff now). Drew