Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!chinet!kdb
From: kdb@chinet.chi.il.us (Karl Botts)
Newsgroups: comp.sys.att
Subject: Re: Any ideas for kernel page fault panic?
Message-ID: <9541@chinet.chi.il.us>
Date: 11 Sep 89 06:40:41 GMT
References: <1717@neoucom.UUCP>
Reply-To: kdb@chinet.chi.il.us (Karl Botts)
Organization: Chinet - Public Access Unix
Lines: 34

>type = 0x02, pid = 25096, pc = 0x6A4, rps=0x2002, p = 0x4a650
>GSR  = 8D00, BSR0 = 7c07, BSR1 = 2000, PHYSPF = 0
>D0=FF, D1=0, d2=90, d3=2
>D4=5, D5=0, D6=CD00, D7=400
>A0=32744, A1=72000, A2=4A670, A3=70E28
>A4=70884, A5=4086E, A6=70820, A7=2FFD18
>
> panic: page fault in kernel
>Press hardware reset to reboot.

I've had the "page fault in kernel" happen to me several times, although
the numbers were different; actually, I only have a copy of the last
one.  Everything up there except for "type", "pid" and "p" are just the
CPU registers.  pid is obvious; I don't know what the other two are.
I am by no means a kernel guru but this is obviously a last-ditch
die-quick exception handler.  One notable difference is that I am pretty
sure when I was getting the message I always got "pid=0", which I suppose
means that my system was running in the kernel itself -- probably handling
a hardware interrupt -- and yours was running in a system call by process
25096.  This means little, except that our events are probably unrelated.

For what it's worth, I am pretty sure that what was causing mine was a
program running in the background catching a SIGSEGV or a SIGBUS.  I had a
program that would hit a bug and die after running for several minutes; I
kept trying to run it in the background and go on about my business.  This
should work, but after I lost a couple of edit sessions I became convinced
that it doesn't.  Getting the system up and running is enough of a hassle
that I did not rigorously test and confirm this hypothesis; however, since
I stopped doing this I haven't had a panic.

Basically, I would guess there is simply a bug in the kernel; and I would
guess that it will never be fixed.  The version we are running now is the
last version of AT&T Unix there will be for this machine, as I understand
it.