Experimental Physics and
Industrial Control System

"J. Frederick Bartlett ([email protected])" <[email protected]> · Mon, 24 Dec 2001 17:06:08 CST

Mark Rivers encountered the following problem:

> In a new EPICS application I am talking to several GPIB devices each at 10
> Hz, and I am getting swamped with "Bad VME interrupt 0" error messages.  The
> problem happens when using the SBS (Greenspring) IP-488 module, mpfGpib1-4,
> VIPC616 carrier, and an MVME2700 PPC CPU.  Andrew Johnson suggested removing
> the logMsg() call in target/config/mv2700/universe.c that generates the
> error.  While this would work, I am getting nearly 100 messages per second,
> and I worry that all these spurious interrupts could be hurting performance.

Mark,

  This may be similar to a problem that I encountered when I moved an
EPICS system from a MVME2301 to an MVME2304. I also saw the "Bad VME
interrupt 0" error message on the MVME2304 but not on the MVME2301.

  When I consulted our local vxWorks expert, Dave Berg, here at
Fermilab, he suggested that it might be the result of the
execution-time optimization that occurs in the 604 processor chip --
the MVME2301 has the 603 processor chip. I note that the MVME2700
series uses the 750 processor chip and I do not know whether it also
uses execution-time optimization.

  Briefly, run-time optimization can result in instructions being
executed in a different order than they appear in memory. Normally
this is not a problem because the processor chip only reorders
instructions that it considers to be independent. However, since it
sees only the local memory bus, there is no means for it to determine
that the register being accessed is, in fact, mapped to a hardware
device that may be sensitive to the order of its register accesses.

  This was apparently what happened with our device where the register
access that cleared the interrupt request was being delayed until just
before (or even after) exiting the interrupt service routine. This
produced an unexpected interrupt since the VME interrupt request line
was still active when the processor priority dropped to a lower level
than the interrupt priority. The problem was alleviated by forcing the
processor to execute the write access to the device register via the
addition of a dummy read access of the same register immediately
following the write access. The optimizing logic recognized that the
write access must be executed first in order for the read access to be
valid.

  I intend to ask Motorola whether there is some means of temporarily
inhibiting the run-time order optimization of these processors and I
will report the results to tech-talk.

  Perhaps you have encountered a similar problem with the 750
processor chip.

						Fritz

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System