Experimental Physics and
Industrial Control System

Kevin Tsubota <[email protected]> · Thu, 27 Dec 2001 10:46:47 -1000

I am also experiencing these "Bad VME interrupt 0" messages while
using VIPC618 carrier boards with an IP330 module in slot D and a MV2304
CPU.

I'm only now starting to look into this problem, but the messages I get seem

spurious and so far isolated to a single VME crate.  I will keep you posted.

> -----Original Message-----
> From: J. Frederick Bartlett ([email protected])
> [mailto:[email protected]]
> Sent: Monday, December 24, 2001 1:06 PM
> To: Mark Rivers
> Cc: [email protected]; [email protected]
> Subject: Re: Error messages wuth IP-488, VIPC616 and PPC604 
> 
> 
> 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