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