ppc826x BAD interrupts

Rob Baxter robb at synergymicro.com
Sat Jan 17 03:35:45 EST 2004

On Fri, Jan 16, 2004 at 11:02:53AM -0500, Jeff Angielski wrote:
> Looking at /proc/interrupts, I see a large number of "BAD" interrups on
> both my MPC8260 reference board (2.4.21) and my PPC8266 custom board
> (2.4.23).  Both use u-boot as the bootloader.
> bash-2.05# cat /proc/interrupts
>            CPU0
>  24:          0   8260 SIU   Edge      PCI IRQ demux
>  33: 2658326944   8260 SIU   Edge      fenet
>  40:      32524   8260 SIU   Edge      uart
>  41:          0   8260 SIU   Edge      uart
> BAD:    8862006  <<====== this the problem
> The source of this count is ppc_spurious_interrupts which is incremented
> in the arch/ppc/kernel/irq.c if:
> 	1) there is no interrupt handler installed
> 	2) SIVEC is showing zero (no interrupts pending)
> Looking into the problem it would appear that the problem is the later
> case and the get_irq() function in ppc8260_pic.c is indeed reading a
> zero from the SIVEC.
> The questions I have are:
> 1) Has anybody seen this behavior on their PowerPC platform?
> 2) Does anybody know why the SIVEC would be showing a zero?
> TIA,
> Jeff Angielski
> The PTR Group

Hi Jeff,

Yes, I have seen this on a PowerPC platform.  And what I have noticed is
that faster (i.e., internal core frequency) the processor the more
likelihood of this happening.  However, it is highly dependent upon the
platform (e.g., interrupting devices, interrupt controller).

A good example is an interrupt request from a PCI bus device.  Many device
driver interrupt handlers will clear the source of the interrupt by either
reading or writing some register within the device, perform some necessary
actions, and return from the handler.  The PCI device is slow to negate its
interrupt request and the interrupt controller sees the interrupt request
from the device again.  With the platforms that I'm associated with I've
seen this happen more frequently (i.e., BAD interrupts) as processor
internal core frequencies increase, especially with the 7457.

Rob Baxter

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-dev mailing list