From owner-freebsd-hackers Mon Dec 4 00:17:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA07908 for hackers-outgoing; Mon, 4 Dec 1995 00:17:36 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA07902 for ; Mon, 4 Dec 1995 00:17:33 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id AAA04466; Mon, 4 Dec 1995 00:17:20 -0800 From: Julian Elischer Message-Id: <199512040817.AAA04466@ref.tfs.com> Subject: Re: Strange crash To: archie@tribe.com (Archie Cobbs) Date: Mon, 4 Dec 1995 00:17:20 -0800 (PST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199512030423.UAA04607@bubba.tribe.com> from "Archie Cobbs" at Dec 2, 95 08:23:12 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1160 Sender: owner-hackers@freebsd.org Precedence: bulk > > > Hi, > > I've been testing a 486DX2-66 Texas Intstruments chip, and it has been > working fine except for a strange crash on bootup that happened once: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x1249b4 nope this is not f01249b4 If the virtual address is that, then the kernel literally jumped into user space.. > fault code = supervisor read, page not present > instruction pointer = 0x8:0x1249b4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 this probably needs some looking at. > current process = 13 (mount) > I did a "nm kernel | sort" on the kernel image and found this: > > f01248e8 T _chdir > f012493c T _chroot > f01249b4 t _change_dir <-- > f0124a4c T _open > f0124ce8 T _ocreat > f0124d14 T _mknod > > On the next reboot, it booted up fine as it has before many times. > Can we assume with high probability that this is some kind of hardware > bug? Is this chip bogus? Any insights would be greatly appreciated!! it looks odd to me.... the leading 'f0' is (I think) significant..... julian