Spurious 8259A interrupt: IRQ7

Filed under: Computers · Date: Sat Jul 12 08:53:56 2003

I've been having "Spurious 8259A interrupt: IRQ7" messages ever since I installed 2.4 (14 IIRC) Linux. Occasionally I experience mysterious system hangs with no explanation. I've switched to a different graphics accelerator (ATI Radeon, previous was nVidia TNT2) so I'd rule X problems out. But since my other hardware is pretty generic, the only problem-maker could be my Telewell ISDN card (Winbond W6692).

I've tried looking answers from the net, but all I can find is some reference to the problem being with SMP and IO-APIC. And other people are telling that there's nothing to worry about, just comment the line from kernel source if you don't like it. But I'm not so convinced.

PROBLEM: spurious 8259A interrupt: IRQ7. AND VM: killing process .., to which Ingo Molnar responds that there's no problem.
Re: 'spurious 8259A interrupt: IRQ7', to which Alan Cox replies it's IO-APIC problem.
[Techtalk] Spurious kernel interrupt? response by Maria Blackmore was actually very informative

From what I read from Maria Blackmore's answer, uniprocessor kernels with APIC enabled can cause spurious interrupts to be generated. Just to be on the safe side, I grepped my kernel configuration for APIC and found out to my amazement it being enabled. I may have switched it on accidentally, thinking it was ACPI.

I'll just recompile the kernel without APIC support and see what happens.

Update August 4, 2003: Due to lack of time or pure laziness, I've been running Linux with append="noapic" instead of installing the kernel image without APIC support. No crashes so far, but I've cought my eye on the spurious interrupt message at least once. I don't have Internet connection at home anymore so I've not booted the machine often enough to see if there's any benefit from the append line. I may be installing the new kernel once I decide to do some coding with it.

Update August 29, 2003: The error message seems to have disappeared after I removed all APIC-related options from the kernel, notably "enable APIC for uniprocessor" option.

Update December 21, 2003: Unfortunately the spurious interrupt or the random system crashes have not disappeared. They may occur more seldom now, but they're still there. I've started to suspect that the Gigabyte motherboard is to be to blame. I've seen some random comments complaining VIA chipsets. it seems they require some black magic to set up properly. Thus it seems to be a kernel driver/chipset incompatibility issue.

I've already made plans to buy a new motherboard and processor next month. A friend of mine recommended a mobo with nVidia nForce chipset -- all the problems he has had with Linux stability went away after he upgraded.

Comments

From Diana · Written on Oct 02, 2003 at 21:02

At installing Linux I have this error when checking the partitions; How can I install Linux?? Please help!

From Axolote · Written on Jan 06, 2004 at 15:28

From what I saw in my research, it's not hw-related. Look at at http://www.ussg.iu.edu/hypermail/linux/kernel/0201.3/0861.html before spending your money. BTW, nForce is great, if you will buy the mobo anyway.

From Juha-Mikko · Written on Jan 07, 2004 at 21:31

Thanks for the tip Axolote! I've now added append="parport=0x378,7" parameter to LILO, and so far everything has gone smoothly. I'll post more about this fix as soon as I've more data on it.

From Dan · Written on Jan 24, 2004 at 05:25

I just bought a PCChips m848ALU mobo with Athlon XP 2500 processor and was having similar problems with an old (circa 1995) ati video card. Whenever I did anything in the graphical terminal it would hang at random points and checking /var/log/messages these hangs would correspond roughly to messages about spurious 8259a interrupts: IRQ7. Notably, i could use the text terminal without causing the system to hang. These two things together make me think that the problem was just with my graphics card So I bought a new NVIDIA MX440 and the problem has dissapeared. I did get one spurious interrupt message the first time I booted up but none since.

From Juha-Mikko · Written on Jan 25, 2004 at 13:14

The spurious 8259A interrupt is most likely an AMD-only problem. But it may be related to bad motherboard and newer ATI graphics accelerator combination. I've seen this error on one mobo with SiS chipset and an old RageII GPU -- for that particular system, the spurious interrupt is harmless. I have VIA KT133 and Hercules Radeon 8500LE. The spurious interrupt hangs my system at a random point after poweron. Sometimes this can happen before X is started, but most often it's a couple of minutes after that.

From Mario · Written on Feb 01, 2004 at 11:17

I've gotten the spurious interrupt message on a Dell Inspiron 1100 laptop running kernel 2.6.2-rc1 (Gentoo). I have the IO-APIC option activated. The only problem I've noticed is that sometimes when starting X, it hangs and only garbage is shown at the screen. Only a cold boot fixes that. I changed the amount of memory available to XFree and the problem seems to have gone away, still, the message is posted to the kernel log.

From Juha-Mikko · Written on Feb 18, 2004 at 21:27

Kai-Steffen Hielscher has made a study on spurious interrupt 7. In his findings, the spurious interrupt goes away with an update to 2.4.18 kernel. I've retired my problematic system, and now I've got a new system based on solid Asus components and Intel P4.

From Mike · Written on Mar 07, 2004 at 22:58

I just bought a new Dell 600SC, installed stock RedHat 9 on it, ran up2date which updated everything to current as of Mar 07, 2004 (including kernel 2.4.20-30.9) and I am seeing this same message on the console: spurious 8259A interrupt: IRQ 7. I have not made any changes to the default installation yet. The motherboard in the Dell 600SC uses a ServerWorks chipset, if that helps anyone... [root@server root]# lspci 00:00.0 Host bridge: ServerWorks GCNB-LE Host Bridge (rev 32) 00:00.1 Host bridge: ServerWorks GCNB-LE Host Bridge 00:02.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) 00:07.0 RAID bus controller: American Megatrends Inc. MegaRAID (rev 02) 00:08.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:0e.0 IDE interface: ServerWorks: Unknown device 0217 (rev a0) 00:0f.0 Host bridge: ServerWorks CSB6 South Bridge (rev a0) 00:0f.1 IDE interface: ServerWorks CSB6 RAID/IDE Controller (rev a0) 00:0f.2 USB Controller: ServerWorks CSB6 OHCI USB Controller (rev 05) 00:0f.3 ISA bridge: ServerWorks GCLE-2 Host Bridge [root@server root]# cat /proc/interrupts CPU0 0: 748144 XT-PIC timer 1: 4 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 0 XT-PIC usb-ohci 5: 22564 XT-PIC megaraid 8: 1 XT-PIC rtc 10: 5376 XT-PIC eth0 11: 0 XT-PIC ide2 12: 104 XT-PIC PS/2 Mouse 14: 58653 XT-PIC ide0 NMI: 0 ERR: 2

From Bob Jacobson · Written on Apr 06, 2004 at 08:09

I too am getting this same error message. I have an ASUS A7N266-VM board with the onboard nvidia 220D GeForce MX Integrated video and an AMD Processor. I have the SAME image (red hat 9) running on an older machine (different board and cpu) that is running great with no problems. The system will totally restart to the login prompt in Gnome right in the middle of using the system. It is very spuratic and it usually happens within a minute after loggin in. It also will eventually lock up the machine with a black screen (this may take a day or two or even a week). If anyone else has some light to shed on this, pleae do. Thanks... Bob

From Bob Jacobson · Written on Apr 06, 2004 at 08:20

I forgot to mention, which I am going to try this this week, I have two 3Com Nic's which are sharing a PCI slot. This ASUS board is in a 1/2 size rack mount case that only allows cards to be parallel with the motherboard, so there is a special card that you plug into the motherboard that allows a side plane to accept 2 pci cards on the side. I was reluctant, but they were both detected. Do you think this may be the issue?

From Juha-Mikko · Written on Apr 07, 2004 at 17:49

Hi Bob. Just before I got a new computer I found a way to deal with the hanging: Just after POST I hit the reset button for a cold reset -- the system rebootet up fine and there was no problems with the spurious interrupt. I have no clue of why it worked. But the solution was not satisfactory. Now I'm running happily Intel hardware.

From Mister Clean · Written on Apr 22, 2004 at 22:43

Don't for a second think that Intel hardware is somehow superior. You just had a crappy motherboard, it sounds like. I'll still take any AMD system over Intel any day.

From Chad · Written on May 05, 2004 at 04:05

I started getting this while installing Gentoo on a old Intel mobile P2 366mhz Dell Latitude CPi. my fix: if this error is killing your install, try to get ssh running, connect to the system from another computer using PuTTY or some such app, logout root from the system itself and do the install from the remote system. that is the only way I was successful.

From Jukka · Written on May 09, 2004 at 22:27

It's actually not (at least from all parts) an AMD-only problem. I've got an HP OmniBook Xe3 GF laptop, which has intel 82830 830 chipset and intel Pentium III M processor. I still get quite randomly these spurious interrupts. But for me, it doesn't cause any problems. All what happends is that I get this message once or twice a week, usually. There are no system freezes or anything.

From P K Mukherjee · Written on Jul 31, 2008 at 10:41

I have a querry regarding 8259-A.
Assuming that PIC has been programmed in AEOI mode and some valid device is connected on IR7.
If now the processor gets an interrupt vector corresponding to IR7, how the processor will find if it is due to noise spike or due to a valid request fro IR7 device.
I shall be thankful, if any one can give me the enswer.
P K Mukherjee

From KenL · Written on Oct 31, 2008 at 05:30

In response to P K Mukherjee.
The interrupt handler for IR7 must first read the Interrupt Request Register (IRR). If the interrupt was real, the bit will be set so you can branch your code to handle the real interupt. If the interrupt was caused by noise or what ever, the bit will not be set and this will be a default interrupt 7. Generally, if it is a default IR7, just issue the EOI and return. This problem cause me to chase a problem for weeks back in the 80’s. I got my first clue about a default interrupt 7 from a 1979 Intel data book on the 8259 PIC.
I hope this helps. Ken

From P K Mukherjee · Written on Nov 03, 2008 at 23:25

Dear Sir,

Thanks for the reply.
But my question was different.

What happens if 8259-A was in AEOI mode.

Regards,
P K Mukherjee

From KenL · Written on Nov 04, 2008 at 06:18

I think I understand your question now. I reread the 8259 data sheet and see that when using the AEOI, the IRR bit gets cleared. This would appear to prevent you from reading the IRR to see if the interrupt was real. In my past experience, I never used the AEOI mode but always used the specific EOI to the interrupt I has handling. Based on what I wee right now, my best advice would be (if you can) change the mode to use a specific EOI so you would be able to tell if the IR7 is real or a default.

I hope this helps. If not, I do not have any other answer for you. Good luck on your project.

Thanks,
Ken

From James · Written on Jun 23, 2009 at 14:26

I have been struggling with this fault on ETX Geode boards (IEM-LX-800-R10 V1.0) – I was able to get rid of it by changing my serial port configuration in BIOS (interestingly, chaning the parallel port configuration had no effect.) I need my serial ports, so dissabling them was not an option – in the end, I was able to get rid of the message so long as I did not configure a serial port to use 2F8/IRQ3.

I wish I could say this has helped me to understand the problem… it is a true mystery.

From Thomas Damgaard · Written on Jul 23, 2009 at 23:21

I get this error too.
I use a fit-PC Geode board.

From Phreakmonkey · Written on Oct 27, 2009 at 07:50

I get this problem on an embedded-system:
NSC Geode Processor
Two 16550 serial ports (irq 4, 3 respectively)
CS5530 IDE controller (irq 14, 15)
3x e100 ethernet ports (irq 5, 10, 11)
No video, no keyboard, no parallel ports.

“spurious 8259A interrupt: IRQ7.”
Kernel 2.6.31.2, no APIC support

From Mzsade · Written on Oct 30, 2009 at 02:27

Spurious interrupt

Spurious 8259A interrupt: IRQ7 has been, and still is a major headache for Linux users. It's often associated with cheap hardware, and causes Linux to crash randomly.