Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!wuarchive!rice!rice!sun-spots-request
From: ames!ultra!beau@uunet.uu.net (Beau James)
Newsgroups: comp.sys.sun
Subject: Re: BUSERR crashes system
Keywords: Miscellaneous
Message-ID: <1990Aug7.003126.1477@rice.edu>
Date: 6 Aug 90 07:03:05 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 23
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 291, message 19
X-Refs:  Original: v9n291, Replies: v9n291

In <1990Aug2.003020.17590@rice.edu> eos!jbm@eos.arc.nasa.gov (Jeffrey Mulligan) writes:

>We have a hardware device which generates a bus error (timeout) to
>indicate a certain error condition.  The vendor-supplied software uses
>mmap() to map the device registers into user space, where most of the work
>is done.  In this case, the bus error causes a BUSERR signal to be sent to
>the user process.

>For various reasons, we need certain functions to be performed in the
>kernel.  Unfortunately, when the statement which causes the bus error is
>executed inside of the device driver, the system panics.

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

Use peekc() / peek() / peekl() and/or pokec() / poke() / pokel() in the
driver.  These routines will trap bus errors, such as timeouts from a
non-existant device, and return an error indication.  See Sun's "Writing
Device Drivers" for details.  Also notice that there is a slight problem
if peek()ing at your device could legitimately return "-1".  So it goes.

Beau James				beau@Ultra.COM
Ultra Network Technologies		{sun,ames}!ultra.com!beau