From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Hans-Peter Jansen <hpj@urpla.net>,
Robert_Hentosh@Dell.com,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: spurious 8259A interrupt
Date: Wed, 24 Mar 2004 10:57:34 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.53.0403241037420.1671@chaos> (raw)
In-Reply-To: <20040324152800.GA5758@mail.shareable.org>
On Wed, 24 Mar 2004, Jamie Lokier wrote:
> Richard B. Johnson wrote:
> > It isn't CPU-specific. It's motherboard glitch specific. If there
> > is ground-bounce on the motherboard or excessive induced
> > coupling, the CPU may occasionally get hit with a logic-level
> > that it "thinks" is an interrupt, even though no controller
> > actually generated it.
>
> That doesn't seem plausible on an otherwise reliable computer.
>
> Why would interrupt lines suffer ground-bounce logic glitches yet all
> the data, address and control lines be fine?
>
> -- Jamie
It is absolutely plausible and, in fact, is what's happening.
An interrupt request is generated by hardware. There is no way
that mucking around with anything in the controller using
software can generate the spurious interrupt. even if you
deliberately enabled interrupts that were not connected
anywhere, they are always pulled to a logic-inactive state
by hardware. I keep hearing these buzzwords like INTA and
DTACK, etc., like you could somehow touch these PWB traces
in software. You can't. The confusion may come about because
with ix86 CPUs it is possible to generate a software interrupt.
I forget what the IRQ offset in Linux is, and I'm not going
to waste time looking it up, I think it's 0x70. So, if a
privileged task executed "int $0x77", the IRQ offset plus
the IRQ number of IRQ7, the code that says "spurious interrupt"
would get executed.
The trace going to the CPU for interrupt have absolutely nothing
in common with any buses. So, the fact that your computer
is otherwise reliable is not relevant. In fact, the spurious
interrupt is not relevant. The CPU time consumed by an
occasional glitch won't affect anything. The kernel logging
message should be commented out.
FYI all your computer hardware is unreliable. There are even bits
getting flipped in memory by cosmic rays as I write this. However,
the likelihood of a bit being flipped in memory that is currently
in use by any program or the kernel at the instant it's flipped
is low enough so you are unlikely to be affected.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
next prev parent reply other threads:[~2004-03-24 15:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 20:32 Robert_Hentosh
2004-03-19 13:06 ` Jamie Lokier
2004-03-19 13:16 ` Russell King
2004-03-19 13:39 ` Jamie Lokier
2004-03-19 14:04 ` Anton Blanchard
2004-03-19 14:56 ` Jamie Lokier
2004-03-19 13:48 ` Richard B. Johnson
2004-03-19 14:39 ` Jamie Lokier
2004-03-21 17:58 ` Hans-Peter Jansen
2004-03-22 9:12 ` Maciej W. Rozycki
2004-03-22 12:29 ` Richard B. Johnson
2004-03-24 15:28 ` Jamie Lokier
2004-03-24 15:50 ` Gabriel Paubert
2004-03-24 15:57 ` Richard B. Johnson [this message]
2004-03-19 13:28 ` Maciej W. Rozycki
2004-03-19 22:01 ` Guennadi Liakhovetski
2004-03-22 9:02 ` Maciej W. Rozycki
2004-03-22 21:16 ` Guennadi Liakhovetski
2004-03-22 22:13 ` Richard B. Johnson
2004-03-22 23:09 ` Guennadi Liakhovetski
2004-03-22 23:38 ` Richard B. Johnson
2004-03-23 10:32 ` Maciej W. Rozycki
2004-03-23 10:42 ` Maciej W. Rozycki
2004-03-23 21:10 ` Guennadi Liakhovetski
2004-03-23 10:29 ` Maciej W. Rozycki
2004-03-23 10:26 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2004-03-16 18:35 Emmanuel Fleury
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=Pine.LNX.4.53.0403241037420.1671@chaos \
--to=root@chaos.analogic.com \
--cc=Robert_Hentosh@Dell.com \
--cc=hpj@urpla.net \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®