Experimental Physics and
Industrial Control System

Timo Korhonen <[email protected]> · Thu, 19 Oct 2000 13:16:12 +0200

The issue of interrupt vector handling in our PowerPC ioc (mv2306) has been a
little bit of an open issue for us until recently. I had to study an existing
driver
(written and running on a 68K cpu) that hung completely and behaved somewhat
randomly when we tried it on our mv2306 ioc's.  The problem turned out to be
the following:

The driver uses functions from devLib.c to connect and disconnect routines to
interrupt vectors: during initialization it connects to a dummy routine to check

if the board works as expected and then, if successful, it disconnects from this

vector and connects to the "real" irq handler.
In vxWorks intArchLib, only a small subset of functions are implemented for
the PPC architecture; notably, functions like intVecGet and intVecSet are not
implemented (although they are in the symbol table and calling intVecGet for
instance always returns zero!)

This behaviour confused the driver, because it could not disconnect from the
first interrupt. devDisconnectInterrupt (in devLib.c) uses intVecGet to get
the connected handler - and gets always NULL, even if the vector was connected.

On mv2306, the VME interrupts come through the interface chip (Tundra Universe)
to a single handler which then dispatches the installed handlers based on the
vector table information.
The vectors are stored in linked lists by the interrupt controller driver. I
wrote a small set of functions with which it is possible to get the
equivalent (I guess....) behaviour to a 68K cpu.
I also have modifications to make the devLib and veclist work.

However, I have a few open questions:

1. The mv2306 structure permits having multiple handlers attached to the same
vector. However, this causes problems for devDisconnectInterrupt (if the
same routine is attached several times with different parameters, there is
no way to tell which one to disconnect.)
Allowing only one routine per vector (like in 68K) should be ok?

2. The code in veclist.c makes a check (cISRTest) where it tries to match the
handler attached to a pointer to a C routine. For those architectures where this

is imported, the call to intConnect constructs a handler from the passed
function; in our ioc, a VOIDFUNCPTR and an int  are just put into a linked
list of handlers. In my patch I do the following: I look for a symbol at the
address
and if a symbol is found, I assume that is a C funtion.  I believe this is a
reasonable assumption?
The generic VME irq handler (in universe.c) calls the user handler like this:

         currHandler->vec (currHandler->arg);

which to me looks pretty much like assuming a C routine.

3. The list of unexpected interrupt handlers is not very relevant in the case of

mv2306, because the Universe interrupt handler checks the vector table and
complains if the interrupt handler entry is NULL.
It is not necessary to have a handler attached to unused vectors. This is just
cosmetics, but in the patches I remove the default vxWorks handler stub
definitions from the table, to avoid confusing error messages during startup.

4. I am not sure if this applies to other than mv2300 series ioc. Because of
this, I used #ifdef MV2300 in the patches.

5. Could the experts help me to sort out the patches so that this could go into
the next release (if they are still relevant)?

I do not attach any code here but I will send it to whoever wants to help (Marty
Kraimer?).

Timo Korhonen/SLS

--
Timo Korhonen  PSI (Paul Scherrer Institut), SLS
               CH-5232 Villigen PSI
               tel + 41- 56 3103262  fax + 41 - 56 310 3151
e-mail:        [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System