jbm@eos.arc.nasa.gov (Jeffrey Mulligan) (08/02/90)
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? Jeff Mulligan (jbm@eos.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 262-2, Moffet Field CA, 94035 (415) 604-3745
jbm@eos.arc.nasa.gov (Jeffrey Mulligan) (08/03/90)
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
beau@uunet.uu.net (Beau James) (08/06/90)
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