EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: VME Bus Error handling on MVME3100 and 6100 boards
From: Andrew Johnson <[email protected]>
To: Till Straumann <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Thu, 10 Aug 2006 14:58:19 -0500
Till Straumann wrote:

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.

Interrupts may not be as quick at actually getting to the CPU as a Target Abort - I don't know whether modern CPUs finish off any/all instructions that they've already started running before they actually switch to processing the exception, but it's likely that there will be a number of instructions pending. This also supposes that interrupts are enabled at the time the bus error gets flagged.


If the Bus Error occurs inside an interrupt service routine, the ISR will get to run to completion, making use of the dud all-1's read data in the process (the vxWorks mv6100 BSP doesn't support nested interrupts, and the hardware doesn't appear to make it easy to do so). If this does occur, the task that happened to be running before the faulting ISR was entered might be incorrectly blamed for causing the error and suspended.

While it might be possible to work around some of these effects it won't be easy to do, and the "unreliable instruction location" behaviour is not something I'd want when debugging a driver.

- Andrew
--
Not everything that can be counted counts,
and not everything that counts can be counted.
  -- Albert Einstein

Replies:
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
References:
VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Kate Feng
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann

Navigate by Date:
Prev: Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·