Date: Wed, 28 Jan 2004 08:51:03 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Tom Ponsford <tponsford@theriver.com> Cc: freebsd-alpha@freebsd.org Subject: Re: Same problem, new year 2100A machine check Message-ID: <16407.48711.708178.207673@grasshopper.cs.duke.edu> In-Reply-To: <4015BB97.70209@theriver.com> References: <4011B6F6.5040306@theriver.com> <40143372.8090207@theriver.com> <16407.1903.816168.318651@grasshopper.cs.duke.edu> <4015BB97.70209@theriver.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tom Ponsford writes: > > 1) Build a kernel with ddb and get a stack trace. > > When the machine crashes and you land at the "db>" prompt, type 'tr' > > I think I did that once before for this list, I think it was a year or so ago. > Here is the backtrace I posted: It was for then 5.0 current > a smp and uniprocessor kernel did exactly the same thing. I seem to vaguely remember a thread like this fizzling out a long time ago. I think the trap is happening at a slightly different place. (well after eisab0 in the 5.0 trace). > I will build a new 5.2 debug kernel though: That would be best. > > I'll have to dig up an alpha that I can spare thats not running on my VMS lan, > so It might be a week or two before I can get a new 5.2 backtrace.. I'm in no rush. <..> > Thanks for all the help!! > No problem.. But I haven't been much help at all. FWIW, having written the 2100 support, I think I'm free to say that 2100 series is totally evil, and you'd be better off using it as a boat anchor, a fish tank, or in some other non-computational capacity... Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16407.48711.708178.207673>