From: Rob Baxter <robb@synergymicro.com>
To: Jeff Angielski <jeff@theptrgroup.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: ppc826x BAD interrupts
Date: Fri, 16 Jan 2004 09:35:45 -0700 [thread overview]
Message-ID: <20040116163545.GA8577@synergymicro.com> (raw)
In-Reply-To: <1074268973.4323.13.camel@localhost.localdomain>
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/
next prev parent reply other threads:[~2004-01-16 16:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-16 16:02 ppc826x BAD interrupts Jeff Angielski
2004-01-16 16:35 ` Rob Baxter [this message]
2004-01-16 20:18 ` Randy Vinson
-- strict thread matches above, loose matches on Subject: below --
2004-01-16 16:29 Muhammad Sarwar
2004-01-16 18:47 ` Jeff Angielski
2004-01-17 3:22 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040116163545.GA8577@synergymicro.com \
--to=robb@synergymicro.com \
--cc=jeff@theptrgroup.com \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).