'spurious 8259A interrupt: IRQ7'
Martin A. Brooks
> chipsets, processor brands, but always IRQ 7. /me wonders.
In my research before posting, a common thread seemed to be the presence of
a tulip card in the machine. Has anyone seen this on a non-tulip box?
Martin A. Brooks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mike_p...@urscorp.com
of
> a tulip card in the machine. Has anyone seen this on a non-tulip box?
Does the same on my laptop, but only after the 3C575 cardbus adapter is
plugged in (using the 3c59x driver).
Mike
Wouter van Bommel
I see it on 1 cpu Athlon machines, but also on 2 CPU pentium III machines.
- Wouter
> -----Original Message-----
> From: linux-ker...@vger.kernel.org
> [mailto:linux-ker...@vger.kernel.org]On Behalf Of szonyi calin
> Sent: Wednesday November 28, 2001 9:59 AM
> To: linux-...@vger.kernel.org
> Subject: Re: 'spurious 8259A interrupt: IRQ7'
>
>
> Hi
> Cx 486, no pci, no network card, same message.
> >From my experience in PC hardware i know that irq 7 is
> usually asigned to the parallel port.
> I know a windoze box which didn't print until i set up
> in bios that paralel port has irq7.
>
> Bye
>
> =====
> *********************************************************
> Désolé, un problème s'est produit :
> * votre signature ne peut pas comporter
> plus de 600 caractères ni occuper plus de
> sept lignes.
> Another way to say: Welcome to Yahoo! ^^^
> **********************************************************
>
> __________________________________________________________
> Obtenez votre adresse @yahoo.ca gratuite et en français !
> courriel.yahoo.ca
PVot...@chemoprojekt.cz
1371 sound card, zip drive on paralell port.. Later I'll try to disable
paralell port in bios and see if that strange message disappears...
--- previous message follows:
> On Tue, Nov 27, 2001 at 02:38:13PM -0000, Martin A. Brooks wrote:
>
> > In my research before posting, a common thread seemed to be the presence
> of
> > a tulip card in the machine. Has anyone seen this on a non-tulip box?
>
> Yup: standard SuSE 7.3 install on an Asus A7V266-E motherboard (VIA KT266A
> chipset, 512 MB DDR, Athlon XP).
>
> Just recently installed Linux on that machine (yesterday evening) so I
> don't even know what kernel version SuSE 7.3 uses. :-( If needed, I can
> try
> other kernels.
>
> --
> Jurjen Oskam * http://www.stupendous.org/ for PGP key * Q265230
> 8:39am up 30 days, 23:33, 1 user, load average: 0.15, 0.03, 0.01
John Mullee
> I also see this messages on various machines each with different hardware.
also here on an Asus A7M266 (Athlon 1.3Ghz, via82c686B, AMD761)
12:48:36 $ grep spurious /var/log/kern.log
Dec 8 22:20:28 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 00:09:47 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 02:22:23 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 02:53:55 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 13:01:22 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 13:22:02 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 15:34:03 www kernel: spurious 8259A interrupt: IRQ7.
Dec 9 22:29:03 www kernel: spurious 8259A interrupt: IRQ7.
Dec 10 23:22:08 www kernel: spurious 8259A interrupt: IRQ7.
Dec 11 01:37:20 www kernel: spurious 8259A interrupt: IRQ7.
Dec 11 17:56:31 www kernel: spurious 8259A interrupt: IRQ7.
12:50:56 $ cat /proc/interrupts
CPU0
0: 6810631 XT-PIC timer
1: 58573 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 2 XT-PIC serial
5: 180477 XT-PIC eth0
9: 0 XT-PIC acpi
10: 1322217 XT-PIC cmpci, eth1
12: 678374 XT-PIC PS/2 Mouse
14: 4785847 XT-PIC ide0
15: 36951 XT-PIC ide1
NMI: 0
LOC: 6810473
ERR: 1378
MIS: 0
It's a hardware problem (usually).
Transient Line-noise/crosstalk persuades the PIC that something
happened; for complicated reasons described below, this can result
in a 'dummy' interrupt being raised, which happens to be IRQ7
with intel's 8259 design.
The problem could possibly also be caused by (or instead be caused by)
a device driver not properly masking it's interrupts before servicing,
this would be the suspect if the IRQ7's were happening in bursts, or
more often than 'several' per day.
Can somebody add this to a FAQ?
Hey, the spurious ints are a nice source of entropy!
Anyone care to write a spurious-IRQ7-handler which feeds the
time-intervals into the PRNG? :) !
john
All hail google:
http://support.intel.com/support/controllers/peripheral/7277.htm
--------------8<------------------
8259A/82C59A-2 Programmable Interrupt Controller
Technical Questions and Answers - Rev 2, Sep '95
Q1. What is it?
A1. The 8259A/82C59A-2 is a programmable interrupt controller (PIC). It
is designed to allow prioritizing and handling of hardware interrupt
requests from peripheral devices, mainly in a PC environment.
Q2. Why is a device like this needed?
A2. I/O devices require servicing in an efficient manner. The PIC allows
I/O devices to be serviced using the "interrupt" technique rather than
with a CPU "polling" technique. The "interrupt" technique allows the
microprocessor to continue to execute its programs and only stop to
service peripheral devices when it is told to do so. The microprocessor
is saved the overhead of determining the source and priority of the
interrupting device.
(snipped ..goes on at length in great detail)
-------------->8------------------
http://support.intel.com/support/controllers/peripheral/7507.htm :
--------------8<------------------
8259/82C59
Spurious IRQ7
In some applications, problem with a spurious IRQ7 might exist. For
example, a spurios IRQ7 will occur under the follwing condition:
While the device is performing extensive I/O operations (IN AL, DX; OUT
DX, AL), an external signal triggers IRQ3. Spurious enabling of IRQ7 and
occassional losing of IRQ3 will be the outcome of this condition.
Design Consideration:
* A spurious IRQ7 occurs, in the 8259, if any interrupt request
duration is too short or hasn't met the setup time required by the 8259A.
* This is a standard 8259 behavior under specific conditions. IRQ7
is triggered when IRQ7 is enabled and is requested
OR
when an interrupt request clears (by itself) before the CPU
services the request. A software solution would be to write an IRQ7
handler that checks the various possible requesters and to handle any
"missed" interrupts from any of those requesters.
PLEASE NOTE:
This product is no longer being manufactured by Intel. THESE DOCUMENTS
ARE PROVIDED FOR HISTORICAL REFERENCE PURPOSES ONLY AND ARE SUBJECT TO
THE TERMS SET FORTH IN THE "LEGAL INFORMATION" LINK BELOW. For
information on currently available Intel products, please see
www.intel.com and/or developer.intel.com
* Legal Information and Privacy Policy Š 2001 Intel Corporation
-------------->8------------------
Novell says this about Netware :
http://developer.novell.com/research/appnotes/1999/septembe/netnotes/04.htm
--------------8<------------------
<snip>
If after all device drivers have been called and no device claims the
interrupt, the NetWare operating system records this event as a
spurious, or not claimed, interrupt event. Large numbers of spurious
interrupts may indicate a problem with the system hardware, device
hardware, or device driver. Spurious interrupts may be ignored by
turning the warnings off using the console command
SET DISPLAY SPURIOUS INTERRUPT ALERTS = OFF.
<snip>
-------------->8------------------
This deeper insight from the BSD FAQ:
http://cynjut.neonramp.com/FAQ_03
--------------8<------------------
<snip>
3.1.5
My system is complaining about stray interrupt 7. Is my machine
going to explode or anything?
No. They are caused by lots of things. They are, as far as
anyone that should be expected to know about this stuff, harmless.
There are ramifications on them being there, but for MOST users
they do not pose a real threat to your operations. For those of
you that are doing REALLY interrupt intensive stuff, you may want
to grab a technical reference and figure out why the 8259 is not
getting reset correctly.
In spite of the number of times this has come up (and people have
even referenced this section) there are still at least two
questions on the net about this. A memorable one was a guy who
was just vehement that the stray int 7 was what was keeping his
system from booting. In fact, he went so far as to say that this
document was practically worthless because I didn't tell him how
to fix it. Of course, once he configured his hard drive controller
so that it was on the right interrupt, his booting problem went
away. I have said it before and I will say it again. For MOST
users they do not pose a real threat to your operations.
I have heard of three people (out of at least 2000) that have
actually have problems so bad that they couldn't proceed. They
bought new computers, and the problem went away.
These stray interrupts are caused by something in the PC.
I have yet to see a convincing explanation of precisely what,
but they are definitely caused by something. There are four
ways to deal with this problem.
1) Ignore them. They are spurious and do not effect the
operation of your computer.
2) Implement the lpt driver. This way, the driver traps
(the lpt driver expects IRQ 7) and then quietly discards them.
That is why when folks implement the lpt driver the 'problem'
goes away. The computer is taught how to ignore them.
3) Do what the original 386bsd code did. Comment out the
diagnostic and associated code that tries to deal with them so
you don't see the error message.
4) Buy a new computer that doesn't cause this problem. It is a
known hardware problem with the 8259 being reset incorrectly in
hardware.
Kalevi Suominen (j...@geom.helsinki.fi) offers this technical
explanation of the 'stray interrupt 7' phenomenon.
In the section of the Intel Peripheral Handbook dealing with
the 8259A there is a description of the 6-step interrupt
sequence for an 80x86 system (and 7-step for an MCS-80/85),
and then the following paragraph:
"If no interrupt request is present at step 4 of either sequence
(i.e., the request was too short in duration) the 8259A will
issue an interrupt level 7. Both the vectoring bytes and the CAS
lines will look like an interrupt level 7 was requested."
This explains how some transient disturbances or improperly
functioning adapter cards could trigger a stray interrupt 7
in a system operating in the *level* interrupt mode (such as
a PS/2 with MCA): An interrupt request will disappear as soon
as the interrupt line goes inactive.
That such interrupts may also occur in a system operating in
the *edge* triggered mode (such as an ordinary PC/AT with ISA)
is a little harder to see. Yet it is possible - even without
malfunctioning hardware - because masking an interrupt request
will hide its presence from the 8259A as well:
1. The interrupt flag (IF) of the 80x86 is reset either
directly (e.g., by a "cli" instruction) or because an
interrupt handler is entered. In the latter case the
corresponding in-service (IS) bit of the 8259A is set
(effectively blocking interrupts of lower priority).
2. The 8259A receives an unmasked interrupt request (IRQn),
and, in case an interrupt is being served and has higher
priority than IRQn, the IS bit of the 8259A is reset by
an end of interrupt (EOI) command. (These steps may occur
in either order.) If IRQn has higher priority (e.g. IRQ0),
no EOI is necessary.
3. The 8259A activates the interrupt (INT) line to the 80x86
(which will ignore it - for the moment).
4. The interrupt mask (IM) bit of the 8259A for IRQn is set.
(A little late, though. The sequence has already started.)
5. The interrupt flag (IF) of the 80x86 is set (either
directly, or as a consequence of e.g. an "iret" instruction).
6. The 80x86 will now acknowledge the INT request by activating
the INTA line of the 8259A.
7. The 8259A will not see the masked IRQn and will continue
by issuing a spurious interrupt of level 7 instead.
The original interrupt request (IRQn) will not be lost, however.
It is preserved by the associated edge sense latch of the 8259A,
and will be acted on after the IM bit has been reset again.
The net result is that a single interrupt request will be
delivered *twice* to the 80x86: first as a stray interrupt 7
and later as the proper interrupt. In particular, it is perfectly
safe to ignore the stray interrupt (other than sending an EOI).
It is just the ghost of an aborted interrupt sequence: the system
was not prepared for it yet.
Bill Roman provides this update, which is so technical I can't
even figure out what to cut out or how to repackage it so it
makes sense to people like me. As an interesting aside, he is
also a Linux user; thereby proving that I'll accept help the FAQ
from everyone:
First of all, Kalevi Suominen's explanation is correct, but
requires just a little more explanation. Step 4 in the data
book concerns the 8259's detection of INTA (interrupt acknowledge)
asserted by the processor. This means that the
processor has detected INT (interrupt request) asserted by the
8259, the previous instruction has ended, and the interrupt enable flag
is true. The processor has begun its interrupt processing, and the 8259
*must* supply a vector; there is no way
for it to tell the processor "never mind".
INTA causes the 8259 to examine the currently asserted interrupt requests
and return the vector corresponding to the highest
current request. If there is no longer any interrupt request
asserted, it supplies vector 7 as a default. (Intel calls this
"DEFAULT IR7" later in the data book.)
There is thus a race condition between deassertion of an interrupt
request and interrupt servicing by the processor. An interrupt request
which is removed will not always cause DEFAULT IR7 --
only if the request is deasserted after the processor has
detected INT and irrevocably decided to act on it, but before
the 8259 has detected INTA and prioritized its interrupts.
It is easy to see how this could happen when the 8259 is in
level triggered mode, but it is counterintuitive that it should
happen in edge triggered mode. To understand this, it is
necessary to look at Intel's "Priority Cell--Simplified Logic
Diagram" (figure 9 in a 1991 databook I have at hand). The edge
sense latch output is gated by the request; if the request is
latched, then deasserted, the 8259 no longer sees it. There
must be a reason Intel did it this way, but it's sure not
evident to me.
The data book provides a little more information in a later
section titled "Edge and Level Triggered Modes". The most
important point is that the corresponding bit in the In Service
Register is *not* set when the 8259 generates a DEFAULT IR7. If
the IRQ 7 interrupt service routine sees this condition (i.e.,
is entered and ISR bit 7 is zero) it should simply execute an
interrupt return instruction without sending an End of
Interrupt (EOI) command to the 8259. Also, the IRQ 7 interrupt service
routine can be reentered due to this condition. Intel
recommends that the interrupt service routine keep track of
whether it is currently active so this can be detected.
I don't think that changing the interrupt mask bit can cause the
problem, especially if it is changed while the interrupt flag is
clear. As I mentioned, the problem occurs only when the actual
interrupt acknowledge process has begun, which can't happen while
IF is clear.
What can generate DEFAULT IR7 is a device driver that doesn't mask
off its device's interrupt (either in the 8259 or in the device
itself) while it is performing operations which can cause the
device to deassert its interrupt request. For example: imagine
a hypothetical device with an interrupt status register. This
register latches all the device's status which could cause an
interrupt, and clears this status when it is read. If the
processor begins executing the instruction which reads this
register just as a status bit is set, the device will assert
and deassert the request within the space of that instruction.
On an x86 architecture processor I have worked with, this did
indeed generate a DEFAULT IR7. All device drivers should make
sure that the device's interrupt request is disabled while the
device is being serviced. A well-behaved device will never
deassert its request without explicit software action.
This leaves only the poor folks who have had to buy new computers
to get rid of the problem. My suspicion in this case is that
crosstalk on the mainboard is causing glitches on interrupt request
lines. Remember that the f**king wizards at IBM made
the request lines active high instead of active low with a
pull-up (which would have allowed wire-or interrupt sharing).
Some devices (some serial port cards, I believe) use a
tri-state driver to drive the request high, but disable the
driver entirely when the request is deasserted, counting on a
weak pull-down. This leaves interrupt request lines floating,
although the 8259 has the inputs enabled. This is all
conjecture, though.
Provided by: Bill Roman (ro...@songdog.eskimo.com)
<snip>
-------------->8------------------