Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!mangler@cit-vax
From: mangler@cit-vax (System Mangler)
Newsgroups: net.unix-wizards
Subject: Re: 4.2BSD panic trap 9 problem on VAX 11/785
Message-ID: <504@brl-tgr.ARPA>
Date: Thu, 8-Aug-85 02:52:30 EDT
Article-I.D.: brl-tgr.504
Posted: Thu Aug  8 02:52:30 1985
Date-Received: Sun, 11-Aug-85 06:21:14 EDT
Sender: news@brl-tgr.ARPA
Lines: 26


    You have run into an old microcode problem of the 780, that
under obscure (to me) circumstances can cause a protection fault
trap when a probe instruction lying within 8 bytes of the end of
the page gets executed.  I think (guess) that it's some wierd
interaction involving the 8-byte prefetch buffer and a page
fault on the probed page.

    Look again at the panic message, and notice that the pc is
evenly divisible by 512.  When it happened on our 780 (right
after adding -DVAX750 to our kernel), the pc pointed to the
instruction
	movl	8(sp),r3
which is certainly innocent enough.  It just happened to be
the first instruction on the new page.	I don't know if it's
important that the instruction landed right on a page boundary.

    I never did find a real solution to it - the local DEC
office had never heard of the problem - so after a couple of
weeks of daily panics, I kludged it by inserting a dozen pad
bytes in front of _Copyout.  (Easiest way is ".space 12").

    You said this happened on a 785.  Gosh, DEC wasn't kidding
when they said the 785 was "bug-for-bug" compatible...

	Don Speck   speck@cit-vax.arpa	ihnp4!cithep!cit-vax!speck