From owner-freebsd-alpha Thu Mar 30 13: 8:16 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C02D137BF22; Thu, 30 Mar 2000 13:08:12 -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.9.3/8.9.3) with ESMTP id QAA10447; Thu, 30 Mar 2000 16:08:10 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id QAA02474; Thu, 30 Mar 2000 16:07:40 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Mar 2000 16:07:40 -0500 (EST) To: wilko@freebsd.org Cc: Dave Haney , freebsd-alpha@freebsd.org Subject: Re: Unexpected machine check In-Reply-To: <20000330225247.C3785@yedi.iaf.nl> References: <20000330201513.A1750@yedi.iaf.nl> <14563.40742.553401.107502@grasshopper.cs.duke.edu> <20000330225247.C3785@yedi.iaf.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14563.49235.18765.586441@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > > I'll try doing that next week. Is there anything special to do when > building the port? You'll need to mess with cflags to switch -O for -g. You do that in one of the xc/config/cf files. I'm not terribly good at building X, so I don't want to lead you astray by suggesting a particular file & being wrong. > > would likely be the PC of the offending instruction. Or close to it. > > Would that be back-traceable to if it is the X server or the kernel? Its the X server; running X doesn't change the kernel's behaviour very much. The X server is what's groping around in device memory. > > In fact, I wonder if we couldn't hack up a kernel to send a sigbus to > > the offending X server & get a core dump rather than panicing. > > Sounds reasonable.. a panic is a bit drastic ;) No, a panic is the correct behaviour. A unexpected, uncorrectable machine check is a sign that something very, very, very bad has happened. In 99.44% of the cases, you want the machine to panic on a machine check. I'm just suggesting a temporary, never-to-be-committed hack to allow you to debug the X server. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message