NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/sgi/11585

Internet Message Format | 1992-07-29 | 1.6 KB

Path: sparky!uunet!dtix!darwin.sura.net!mips!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!eagle!bach.lerc.nasa.gov!fsset
From: [e-mail] (Scott Townsend)
Newsgroups: comp.sys.sgi
Subject: VME differences between 4D/20 & 4D/35?
Message-ID: <[e-mail]>
Date: 29 Jul 92 15:13:01 GMT
Sender: [e-mail]
Distribution: na
Organization: NASA Lewis Research Center [Cleveland, Ohio]
Lines: 23

I have a machine here that was recently upgraded from a 4D/20 running 3.3.(2?)
to a 4D/35 running 4.0.1.  It has a Bit3 VME-VME adaptor in it used to
connect to an external VME bus.

Prior to the upgrade things had been running fine.  I'm now experiencing
fairly odd behaviour which might be related to the VME implementation
in the 4D/35.  "Odd behaviour" includes things like write(2) returning -1
_and_ setting errno to -1 (fixed by using memcpy from VME to local buffer
and then writing the local buffer to the socket), SIGBUS on valid VME
addresses in an almost repeatable fashion, etc.

Is there anyone out there who could tell me what (if anything) has changed
in the VME implementation, or could point me to documentation?

NOTE: there's no kernel driver code in question here, the VME adaptor merely
      supplies a window into the remote VME bus via a suitable mmap() call.
      Ordinary user-level code then uses the window to do reads & writes
      of remote memory.  The remote system does NOT access the Iris or pass
      any interrupts to it.

--
Scott Townsend,  Sverdrup Technology Inc.  NASA Lewis Research Center Group
[e-mail]