Date: Thu, 30 Mar 2000 16:07:40 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: wilko@freebsd.org Cc: Dave Haney <dave@engg.ksu.edu>, freebsd-alpha@freebsd.org Subject: Re: Unexpected machine check Message-ID: <14563.49235.18765.586441@grasshopper.cs.duke.edu> In-Reply-To: <20000330225247.C3785@yedi.iaf.nl> References: <Pine.SO4.4.00.10003291814390.21551-100000@phobos.engg.ksu.edu> <20000330201513.A1750@yedi.iaf.nl> <14563.40742.553401.107502@grasshopper.cs.duke.edu> <20000330225247.C3785@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14563.49235.18765.586441>