NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/vxworks/670

Internet Message Format | 1992-07-23 | 6.2 KB

Path: sparky!uunet!pmafire!news.dell.com!swrinde!mips!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!dog.ee.lbl.gov!lbl.gov!vxwexplo
From: [e-mail] (Phil Shaffer)
Newsgroups: comp.os.vxworks
Subject: Spurious Interrupts on Motorola boards: Summary
Message-ID: <[e-mail]>
Date: 23 Jul 92 21:41:44 GMT
Sender: [e-mail]
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Lines: 110
NNTP-Posting-Host: 128.3.112.16
Originator: [e-mail]


Some time ago I posted a query asking what might be causing
Spurious Interrupts on Motorola MVME165 and MVME167 boards.
I was getting error messages such as:

Interrupt to uninitialized vector number 24 (0-255).
Equivalent to vector-> Spurious Interrupt
Program Counter: 0x000021c8
Status Register: 0x3100

This was on a Motorola MVME165 (68040) processor, running vxWorks 5.0.2
(VADworks 2.0.2b). It is in a chassis with other 68040 processors,
one of which sends it messages, using a "notification" scheme
we developed, based on the SIGLP interrupt on the VMEchip.
The SIGLP interrupt service routine turns off the SIGLP interrupt then puts
some data in a queue and then does a semGive.  In the regular code,
when semTake is satisfied, the SIGLP interrupt is turned off by
notify_int_disable, then the data are removed from the queue and
the interrupt is turned back on.  The spurious interrupt was
occurring at the very end of notify_int_disable or just after its return.
Also, when the spurious interrupt occurs, the processor sometimes
(but not always) misses an interrupt it should have received.
The same problem was occurring on MVME147 and MV167 cards also.

The most concise summary of what causes spurious interrupts was from  [e-mail]:

>a "Spurious Interrupt" is generated when one of the IRQ
>lines gets pulled but no one responds with an interrupt vector during
>the IACK bus cycle thus resulting in a bus timeout error, which is reported
>as "Spurious Interrupt" rather than as an ordinary bus error.  See pg 8-37
>in the 68040 User's Manual for Motorola's explanation.  (It was clearer
>in the old 030 Manuals.)

>... your status register is showing interrupt priority mask = 1
>(bits 8-10 of SR) thus I would suspect that you have a device pulling
>IRQ 1. ...  If SIGLP is pulling IRQ 1, then I would further suspect the 167
>to have a hardware bug.

SIGLP does cause a Level 1 interrupt, and nothing else should have caused
such an interrupt.

[e-mail] (Carl Chesbrough) suggested:
>This could
>be from having the interrupt present, and then removed before the interrupt
>acknowledge cycle has completed, thus not having a vector and data ack cycle.

Other suggestions of missing IACK jumpers on the backplane or trashed
interupt vector table missed the mark because the occurrence was intermittent.

The problem was occurring because I was turning off the SIGLP interrupt
when these interrupts were occurring at rapid rates, thus occasionally
SIGLP would get turned off in the middle of an IACK cycle, preventing
the interrupt vector from being placed on the local processor bus.  Note
that the VMEbus had nothing to do with the problem.

Thanks to Darryl Coy, a Systems Engineer from Motorola, for suggesting
the solution: rather than turn off SIGLP to prevent interruption
when manipulating data structures shared between the ISR and non-ISR
code, raise the processor priority in non-ISR code to force any interrupts
to hold until non-ISR code is complete with the critical section.  I wrote
a small assembly routine to manipulate the 68040 Status Register.  This
worked perfectly!

It seems to me the problem is a hardware deficiency in the Motorola
boards, and that once the VMEchip starts an interrupt cycle, it shouldn't
be possible to break that cycle.  However Darryl Coy
(mcddyt![e-mail]) says:
>once the VMEchip2 asserts an interrupt (via VMEbus master writing to the
>SIG bit), the program should NOT disable the SIG).  Why?  Because the
>68040 will respond with an IACK cycle.  The interrupting device must
>then respond.  If the SIG is turned off and IACK cycle is started, then
>the hardware logic on the VMEchip2 will not respond to the IACK cycle.
>Thus, this situation leads to the spurious interrupt.  In conclusion,
>removing interrupt requests before they are acknowledged is a big nono...

If you are not in interrupt code, how can you know an interrupt cycle
has started?  Anyway, raising priority solves the problem.

A similar situation was described by [e-mail]:
>from an on board
>timer of a Synergy SV31 (50Mhz '030).  Someone had written a
>"taskDelayQuick", which used an aux timer to suspend a task for a few
>milliseconds (not tied to the vxWorks tick rate).  The routine set the
>timer up in a free-running clock mode - that is it generate interrupt at an
>even rate.  The service routine turned off the clock after the first
>interrupt and resumed the suspended task.  Under heavy interrupt load (VME
>and mailbox) with a very short delay, spurrious interrupts would occur.
>Stan "the man" at Synergy saw this before and told me where to look.  It
>seems that the '030 isr can turn off the clock (from the fist interrupt) at
>the same time that the clock chip is asserting the next interrupt.  When
>the '030 then runs its IACK cycle, the timer chip has just been cleared and
>does not acknowledge and a bus error occurs on board.

So be careful when you turn interrupts off - it can cause problems.

My thanks to all who offered suggestions.

One other note: of 6 MVME167 cards we have, only one occasionally (once per
1-5 minutes) has a spurious interrupt when nothing but the "default"
vxWorks processes, including NetTask, are running.  This may be
a case of marginal or flaky performance of the "ei" ethernet chip.
[e-mail] (Marc Ullman) also mentioned a case of
marginal performance on the 167, and solved it by increasing bus timeout
to 256usec.  Has anyone else seen spurious interrupts on a 167 that is
not doing anything (other than watching the Ethernet)?

     Phillip L. Shaffer                  [e-mail]
     GE Aircraft Engines, MS A320        uunet!stef.crd.ge.com!shaffer
     1 Neumann Way
     Cincinnati, OH 45215