Date: Wed, 24 Mar 2004 10:57:34 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Reply-To: 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
In-Reply-To: <20040324152800.GA5758@mail.shareable.org>
Message-ID: <Pine.LNX.4.53.0403241037420.1671@chaos>
References: <6C07122052CB7749A391B01A4C66D31E014BEA49@ausx2kmps304.aus.amer.dell.com>
 <20040319130609.GE2650@mail.shareable.org> <Pine.LNX.4.53.0403190825070.929@chaos>
 <200403211858.07445.hpj@urpla.net> <Pine.LNX.4.53.0403220713160.13879@chaos>
 <20040324152800.GA5758@mail.shareable.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2457
Lines: 57

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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/