Spurious 8259A interrupt: IRQ7 ????
What does it mean this message?
Of what problem is the signal?
There is a way to solve this? (Next kernel versions) or is an HW problem? (Motherboard MSI KT7 Ultra)
Thanks
Bye
Quoted 3 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
It is most likely a hardware problem.
When a device signals an interrupt, it asserts its interrupt pin. When the CPU asks the interrupt controller what device generated the interrupt, the interrupt controller tells the CPU.
But if the interrupt line "goes away" before the CPU fetches the vector, then the interrupt controller doesn't "know" what IRQ caused the interrupt. So the interrupt controller sends an IRQ #7 to the CPU, along with setting a bit in the interrupt controller's status register that says in effect "this isn't really an IRQ 7, but I have no idea what it was. Sorry."
If you have ISA cards in your system, remove them from the system and re-insert them (with the power off, of course) - they may have developed some oxidization on the card edge connector. You can also try scrubbing the card edge with some plain paper (a US dollar bill works even better, but you might not have access to dead presidents in Italy.)
Ditto with PCI cards - remove them, polish the connector, then re-insert them.
Have seen this problem with a motherboard with a bad PCI slot, too. happened with a pci network card in the slot...
Chad Schwartz
CornerNet System Administration
Quoted 34 lines · David D. Hagood
Quoted 3 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
It is most likely a hardware problem.
When a device signals an interrupt, it asserts its interrupt pin. When the CPU asks the interrupt controller what device generated the interrupt, the interrupt controller tells the CPU.
But if the interrupt line "goes away" before the CPU fetches the vector, then the interrupt controller doesn't "know" what IRQ caused the interrupt. So the interrupt controller sends an IRQ #7 to the CPU, along with setting a bit in the interrupt controller's status register that says in effect "this isn't really an IRQ 7, but I have no idea what it was. Sorry."
If you have ISA cards in your system, remove them from the system and re-insert them (with the power off, of course) - they may have developed some oxidization on the card edge connector. You can also try scrubbing the card edge with some plain paper (a US dollar bill works even better, but you might not have access to dead presidents in Italy.)
Ditto with PCI cards - remove them, polish the connector, then re-insert them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · David D. Hagood
Quoted 3 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
It is most likely a hardware problem.
It can occur for lots of harmless software reasons too. If you disable the IRQ on a device just as the PIC sees it you may see this result for example.
Really for 7/15 on a PC we shouldnt be bugging people
Quoted 2 lines · David D. Hagood
It is most likely a hardware problem.
I wouldn't necessarily assume a hardware problem (unless we also include chipset oddities). I get *exactly* one message stating exactly this per boot, and it always come a few seconds after loading the parport and parport_pc modules.
one example:
Jan 20 09:20:21 testing kernel: parport0: PC-style at 0x378 [PCSPP,EPP] Jan 20 09:20:21 testing kernel: parport_pc: Via 686A parallel port: io=0x378 <snip> Jan 20 09:20:07 testing kernel: spurious 8259A interrupt: IRQ7.
-Tupshin
Quoted 9 lines · Tupshin Harper <[email protected]>, on Mon Jan 20, 2003 [09:22:35 PM] said:
Quoted 2 lines · David D. Hagood
It is most likely a hardware problem.
I wouldn't necessarily assume a hardware problem (unless we also include chipset oddities). I get *exactly* one message stating exactly this per boot, and it always come a few seconds after loading the parport and
parport_pcmodules.
Quoted 8 lines
one example:
Jan 20 09:20:21 testing kernel: parport0: PC-style at 0x378 [PCSPP,EPP] Jan 20 09:20:21 testing kernel: parport_pc: Via 686A parallel port: io=0x378 <snip> Jan 20 09:20:07 testing kernel: spurious 8259A interrupt: IRQ7.-Tupshin
Hi; I see it just once every boot, and I dont have any parallel
port stuff enabled. (2.5.59)
Quoted 9 lines · David D. Hagood
Quoted 3 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
It is most likely a hardware problem.
Quoted 10 lines
When a device signals an interrupt, it asserts its interrupt pin. When the CPU asks the interrupt controller what device generated the interrupt, the interrupt controller tells the CPU.
But if the interrupt line "goes away" before the CPU fetches the vector, then the interrupt controller doesn't "know" what IRQ caused the interrupt. So the interrupt controller sends an IRQ #7 to the CPU, along with setting a bit in the interrupt controller's status register that says in effect "this isn't really an IRQ 7, but I have no idea what it was. Sorry."
If you have ISA cards in your system, remove them from the system and re-insert them (with the power off, of course) - they may have developed some oxidization on the card edge connector. You can also try scrubbing the card edge with some plain paper (a US dollar bill works even better, but you might not have access to dead presidents in Italy.)
Ditto with PCI cards - remove them, polish the connector, then re-insert them.
Thank you very much all of you for the answers.So, this should be an harmless message, I've tried to attach something to the parallel port , or disable it in the bios, but doesn't work, the only way to remove this problem is to load the parport_pc module, this message with the module loaded doesn't appear. I've tried with other bioses , and the problem appears on all of them. If I compile in the kernel UP-IO-ACPI the problem disappears, but I have a lot of other problems, because my system is quite young and the support for IO-APIC is not added yet for me.If I use only UP-APIC this problem appears, and if don't use apic this disappears.
I'll try to remove some HW and retry. Someone had this problem without APIC enabled?
Thank you
Bye
Marcello
Quoted 45 lines · AnonimoVeneziano
Quoted 27 lines · David D. Hagood
Quoted 3 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
It is most likely a hardware problem.
When a device signals an interrupt, it asserts its interrupt pin. When the CPU asks the interrupt controller what device generated the interrupt, the interrupt controller tells the CPU.
But if the interrupt line "goes away" before the CPU fetches the vector, then the interrupt controller doesn't "know" what IRQ caused the interrupt. So the interrupt controller sends an IRQ #7 to the CPU, along with setting a bit in the interrupt controller's status register that says in effect "this isn't really an IRQ 7, but I have no idea what it was. Sorry."
If you have ISA cards in your system, remove them from the system and re-insert them (with the power off, of course) - they may have developed some oxidization on the card edge connector. You can also try scrubbing the card edge with some plain paper (a US dollar bill works even better, but you might not have access to dead presidents in Italy.)
Quoted 5 lines
Ditto with PCI cards - remove them, polish the connector, then re-insert them.
Thank you very much all of you for the answers.So, this should be an harmless message, I've tried to attach something to the parallel port , or disable it in the bios, but doesn't work, the only way to remove this problem is to load the
parport_pcmodule, this message with the module loaded doesn't appear. I've tried with other bioses , and the problem appears on all of them. If I compile in the kernel UP-IO-ACPI the problem disappears, but I have a lot of other problems, because my system is quite young and the support for IO-APIC is not added yet for me.If I use only UP-APIC this problem appears, and if don't use apic this disappears.
Quoted 8 lines
I'll try to remove some HW and retry. Someone had this problem without APIC enabled?
Thank you
Bye
Marcello
If it bothers you, just comment out the message in the kernel. A "catch-all" for interrupt glitches is the IRQ7. It can be caused by real problems (unlikely if the rest of the machine works), or the occasional glitch where some hardware didn't assert its IRQ line long enough for it to be recognized. This is a hardware glitch and they happen. They started to happen more often once level interrupts, necessary for PCI interrupt sharing, started to become common. Level interrupts, as opposed to edge interrupts are not latched. If a glitch occurs on a edge interrupt, the event is latched. If enabled, the interrupt is handled just like a "real" one and nobody is the wiser. With level interrupts, the CPU can become "confused" with a glitch if, by the time the CPU starts to handle the interrupt, it no- longer exists. The result is that the CPU executes the IRQ7 handler, the "catch-all", which is also used for the printer.
Bottom line, it's normal. It's being handled. You probably should just comment out the message in "production" software so it doesn't bother anybody.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
i get it on my thinkpad 560e when using a linksys ne2k pcmcia card. i only get the message once, and it's triggered after a few seconds of high throughput (fast, fd).
Signature · 2 lines
Tom Vier <[email protected]> DSA Key ID 0xE6CB97DA
Quoted 6 lines
I wouldn't necessarily assume a hardware problem (unless we also include chipset oddities). I get *exactly* one message stating exactly this per boot, and it always come a few seconds after loading the parport and
parport_pcmodules.Jan 20 09:20:07 testing kernel: spurious 8259A interrupt: IRQ7.
I also see this message on every boot... I have two Soyo SY-KT400 Dragon Ultra mother boards, and the message appears with both of them. Perhaps it is some VIA oddity?. Anyhow, it does not seem to have any harmful effects (both boards are rock solid with 2.4.20).
Dec 23 20:34:37 mood kernel: Real Time Clock Driver v1.10e Dec 23 20:34:37 mood kernel: spurious 8259A interrupt: IRQ7.
Signature · 4 lines
[Ville Hallivuori][[email protected]][http://www.iki.fi/vph/] [ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62 5D 87 47 9D 3F 2B 07 5D] [ID 58543419][FP20=8731 941D 15AB D4A0 88A0 FC8F B55C F4C4 5854 3419] [ID 8061C24E][FP20=C722 12DA 841E D811 DBFE 2FB3 174C E291 8061 C24E]
From: Ville Hallivuori <[email protected]>
Date: Wed, 22 Jan 2003 22:06:30 +0200
Quoted 1 line
Dec 23 20:34:37 mood kernel: spurious 8259A interrupt: IRQ7.
Could we possible append an URL to Intels' spec to reduce the traffic here? Any volunteer to do that?
Signature · 5 lines
Pavel Janík
I'm simply not a good maintainer, because I'm too impatient and get too
bored with it.
-- Linus Torvalds in LKMLQuoted 10 lines · Ville Hallivuori
Quoted 9 lines
I wouldn't necessarily assume a hardware problem (unless we also include chipset oddities). I get *exactly* one message stating exactly this per boot, and it always come a few seconds after loading the parport and
parport_pcmodules.Jan 20 09:20:07 testing kernel: spurious 8259A interrupt: IRQ7.
Quoted 11 lines
I also see this message on every boot... I have two Soyo SY-KT400 Dragon Ultra mother boards, and the message appears with both of them. Perhaps it is some VIA oddity?. Anyhow, it does not seem to have any harmful effects (both boards are rock solid with 2.4.20).
Dec 23 20:34:37 mood kernel: Real Time Clock Driver v1.10e Dec 23 20:34:37 mood kernel: spurious 8259A interrupt: IRQ7.
When I enable I/O APIC the problem disappear , it is present only if I enable Local APIC. There is a possibility that that IRQ is an IRQ of I/O APIC , and when it is disabled it isn't initialized with Local APIC only . In this case the message can be ignored without any preoccupations
Bye
Marcello
Quoted 4 lines
i get it on my thinkpad 560e when using a linksys ne2k pcmcia card. i only get the message once, and it's triggered after a few seconds of high throughput (fast, fd).
Same here with an Acer TravelMate laptop, with an smc pcmcia network card. The message occures only once at high network load. But the system is quite stable, so I didn't bother to track this down...
Oh, and the laptop is based on Ali, not on VIA chips.
Zsolt.
Signature · 3 lines
"The secret to strong security: less reliance on secrets."
-- Whitfield Diffie --A glitch on any interrupt line, will cause IRQ7 to trigger on the 8259A.
It is a documented 'feature' and is not really useful, but software
has to handle it gracefully.
Quoted 12 lines · Zsolt Babak
Quoted 4 lines
i get it on my thinkpad 560e when using a linksys ne2k pcmcia card. i only get the message once, and it's triggered after a few seconds of high throughput (fast, fd).
Same here with an Acer TravelMate laptop, with an smc pcmcia network card. The message occures only once at high network load. But the system is quite stable, so I didn't bother to track this down...
Oh, and the laptop is based on Ali, not on VIA chips.
Zsolt.
I've noticed also that the number indicated by the ERR field in /proc/interrupts increase slowly with the time.
But, at the end of all I haven't understood well what is this error, and what the ERR field indicates. And why with IO-APIC it disappears? (IO-APIC gives me very much problems with ACPI :-( )
Bye
Quoted 15 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
There is a way to solve this? (Next kernel versions) or is an HW problem? (Motherboard MSI KT7 Ultra)Thanks
Bye
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It is a hardware 'feature', but nothing to worry about. The software just has to live with it. This problem is as old as the PC itself, dating back to the original IBM design from 1981.
Cheers,
Signature · 7 lines
Herman Oosthuysen B.Eng (E), Member of IEEE Aerospace Software Ltd http://www.AerospaceSoftware.com Phone: 1.403.852-5545, Fax: 1.403.241-8841 E-mail: [email protected] E-mail: [email protected]
Quoted 31 lines · AnonimoVeneziano
I've noticed also that the number indicated by the ERR field in
/proc/interruptsincrease slowly with the time.
But, at the end of all I haven't understood well what is this error, and what the ERR field indicates. And why with IO-APIC it disappears? (IO-APIC gives me very much problems with ACPI :-( )Bye
Quoted 7 lines · AnonimoVeneziano
What does it mean this message?
Of what problem is the signal?
There is a way to solve this? (Next kernel versions) or is an HW problem? (Motherboard MSI KT7 Ultra)Thanks
Quoted 8 lines
Bye
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/