Date: Mon, 29 Jul 1996 10:58:05 -0400 From: Chris Shenton <cshenton@it.hq.nasa.gov> To: lithium@cia-g.com Cc: hardware@freebsd.org, hackers@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <199607291458.OAA01389@wirehead.it.hq.nasa.gov> In-Reply-To: Your message of "Fri, 26 Jul 1996 16:13:08 -0600 (MDT)" References: <Pine.LNX.3.91.960726152443.17109A-100000@gallup.cia-g.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Jul 1996 16:13:08 -0600 (MDT) Stephen Fisher <lithium@cia-g.com> wrote: lithium> (This is running 2.1.5R, I had the same problems with 2.1R). lithium> Sometimes the machine will even "Freeze" and reboot in the lithium> middle of doing something with no warning..:] lithium> lithium> Fatal tral 12: page fault while in kernel mode lithium> Fault virtual address = 0xfc7 lithium> Fault code = supervisor read, page not present lithium> Instruction pointer = 0x8:0xf0181de2 lithium> Code segment = base 0x0, limit 0xfffff, type 0x1b lithium> DPL 0, pres 1, def32 1, gran 0 lithium> Processor eflags = interrupt enabled, resume, IOPL = 0 lithium> Current process = 249 (cpp) lithium> Interrupt mask = lithium> panic: page fault lithium> lithium> As I said it almost always happens on the same instruction lithium> pointer. The process can be anything but it usually occurs lithium> with gcc (such as when compiling the kernel, I can't even get lithium> a minute or two into the compile). lithium> lithium> Hardware: 16meg of parity ram, AMD DX4/100, SiS 85c471 lithium> chipset motherboard (ick!) with VLB bus, Adaptec 284x SCSI lithium> controller, S3 video card, etc. I just brought up 2.1.5R on an AMD486-100 and got a very similar problem after rebuilding the kernel. It spat out this kind of error -- in random processes like sh and inetd -- and failed to boot. At the time I was trying to compile in support for a GUS MAX and PC Audio devices. I also noticed I was getting file corruption, as if my disk was dying or some such, so I suspect that possibly the kernel file also had corruption, causing a bogus instruction to be executed. I just re-installed on a new disk, so if this disappears, I'll blame the drive. If not, I'm not sure :-(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607291458.OAA01389>