Re: VME Bus Error handling on MVME3100 and 6100 boards

[Till Straumann <strauman@slac.stanford.edu>]

-- snip --

> > This behaviour is not possible with the Tempe chip - VME read cycles 
> > that terminate with a Bus Error just return 0xFFFF values (all one 
> > bits), and by default there is no indication that anything unusual 
> > happened.  It is possible to enable the VME Exception interrupt, which 
> > will eventually be serviced by the processor and most of the time 
> > would allow the BSP to suspend the correct task (assuming that the Bus 
> > Error wasn't caused by an Interrupt Service Routine), but that 
> > interrupt could be delayed for quite a long time by other pending 
> > interrupts.

So why would you care? The faulting task would still not be able
to make any progress and hence be suspended right at the faulting
instruction.

I'd be more concerned about the other side-effect (I just snipped out):
If indeed the entire write-fifo is flushed when a bus error occurs
then legitimate write operations might be lost.

-- Till

> >
> > The only sure-fire way around this problem is to check the Tempe 
> > chip's VMEbus Exception Attributes Register after every write 
> > operation and every read that returns an all-1s bit pattern - clearly 
> > not something conducive to good I/O performance, and not compatible 
> > with any existing EPICS drivers.



> >
> > As a result of the above, I would recommend that EPICS users avoid any 
> > VME CPU board that uses the Tundra Tsi148 (Tempe) chip, and explain to 
> > your Motorola sales representative why you are doing so.
> >
> > - Andrew
> 
> 
>