NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/os/vms/17544

Internet Message Format | 1992-11-06 | 3.7 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!fnnews.fnal.gov!fnnews!SNYDER
From: [e-mail]
Newsgroups: comp.os.vms
Subject: Problems with DEC's XMI-VME adapter
Date: 05 Nov 92 23:09:23 GMT
Organization: SUNY Stony Brook High Energy Physics
Lines: 66
Message-ID: <[e-mail]>
NNTP-Posting-Host: d0sb10.fnal.gov


Hi -

I've been trying to use DEC's XMI-VME interface (DWMVA).
Our machine is a Vax 6000-610 with one CPU, and we're running
VMS 5.5-2HW.

The first problem occurred when i tried to connect a driver to the
adapter.  The system died immediately with an INCONSTATE bugcheck.
The driver was sys$examples:qsdriver.mar (which i had modified slightly,
but i did not touch the DPT, DDT, or the initialization routines).

I eventually tracked this down to the following:
When sysgen is connecting a driver to an adapter, it first
tracks down the adapter's ADP.  Now, the ADP has a field of
capability flags, ADPDISP_FLAGS, which are used by the ADPDISP macro.
There is also a flag which says whether or not the rest of the flags
have been initialized.  For some devices, VMS initializes this field
during system initialization; for others, including the VME adapter,
it does not.  Before connecting a driver, sysgen checks this ADP
field and issues a fatal bugcheck if it has not been initialized.
This is apparently a recent change, as this check is not present in
the V5.5 source listings.  (It looks like someone replaced that big
nest of compare/branches that dispatch into adapter-specific code in
the sysgen connect routine with ADPDISP, forgetting, perhaps, that
ADPDISP will bugcheck if ADPDISP_FLAGS is not set.)

Anyway, i was able to deal with this problem by throwing together
a small program which tracks down the VME adapter's ADP and pokes
a 1 into ADPDISP_FLAGS.  What i was wondering is: is this a known problem,
and how have other people dealt with this?

The second class of problems concerns error handling.  It seems that
if there is a VME bus error or if the VME crate is powered off or
disconnected, the vax gets a fatal (INT60) exception on the XMI
and bugchecks with UNXINTEXC.  While i suppose one could argue that
this might be the `proper' response, this makes things rather inconvenient,
since the only machine we have that the VME adapter will work in is also used
in our data acquisition system.  If at all possible, i'd like the
vms system to be able to survive a failure on the vme end.  So far,
i've thought of two possible strategies for doing this:

- Disable all error interrupts from the adapter.  Have the process which
  is reading out the vme test for errors by periodically polling the
  device error registers.  This has the disadvantage that we might have
  to duplicate DEC's error analysis/recovery code for the adapter.
  In addition, if we don't check for errors often enough, there is
  the possibility that the system could be hung up for substantial
  periods of time waiting for bus timeouts.  And would we still get
  XMI exceptions?

- Patch the VME adapter's IVINTR routine so that when it goes back to
  the INT60 handler, the bugcheck flag does not get set.  If the
  INT60 handler dismisses the exception, will the system be able
  to continue running?  And there is the question of how to report
  errors back to user-mode code.  Ideally, if the exception was
  caused by a process reading from or writing to memory mapped to the
  vme, one would like to send an exception to that process, but that
  seems rather tricky.

Anyway, i'd be interested to hear if anyone else has tried to deal
with this, or just any interesting war stories concerning this adapter.

thanks,
scott snyder
[e-mail]