Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!rice!rice!sun-spots-request
From: eos!jbm@eos.arc.nasa.gov (Jeffrey Mulligan)
Newsgroups: comp.sys.sun
Subject: Re: BUSERR crashes system
Keywords: Miscellaneous
Message-ID: <1990Aug5.165238.11168@rice.edu>
Date: 3 Aug 90 01:21:19 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 18
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 291, message 11
X-Refs:  Original: v9n291

I posted too soon; yesterday afternoon (a couple of hours after posting) I
found the answer to my question:

eos!jbm@eos.arc.nasa.gov (Jeffrey Mulligan) writes:

>Q:  Is there any way to trap and deal with this type of event inside
>the kernel?

[bus error caused by kernel reference of a non-existent VME location]

Eventually I realized that this type of event is exactly what occurs in
the probe/attach sequence, so I looked in the probe routine and saw that
locations are queried with peek() and poke(), which are documented in TFM,
which says that they are only used in probe/attach routines.

	Jeff Mulligan (jbm@eos.arc.nasa.gov)
	NASA/Ames Research Ctr., Mail Stop 262-2, Moffet Field CA, 94035
	(415) 604-3745