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
AnonimoVeneziano wrote:
> 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
On Mon, 20 Jan 2003, David D. Hagood wrote:
> AnonimoVeneziano wrote:
> > 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/
>
On Tue, 2003-01-21 at 00:36, David D. Hagood wrote:
> AnonimoVeneziano wrote:
> > 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
David D. Hagood wrote:
> 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
Tupshin Harper <[email protected]>, on Mon Jan 20, 2003 [09:22:35 PM] said:
> David D. Hagood wrote:
>
> >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
>
Hi;
I see it just once every boot, and I dont have any parallel
port stuff enabled. (2.5.59)
Paul
[email protected]
David D. Hagood wrote:
> AnonimoVeneziano wrote:
>
>> 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.
>
>
>
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
On Tue, 21 Jan 2003, AnonimoVeneziano wrote:
> David D. Hagood wrote:
>
> > AnonimoVeneziano wrote:
> >
> >> 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.
> >
> >
> >
> 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
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).
--
Tom Vier <[email protected]>
DSA Key ID 0xE6CB97DA
> 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.
> 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.
--
[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
> 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?
--
Pavel Jan?k
I'm simply not a good maintainer, because I'm too impatient and get too
bored with it.
-- Linus Torvalds in LKML
Ville Hallivuori wrote:
>>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.
>>
>>
>
>
>
>>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.
>
>
>
>
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
> 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.
--
"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.
Zsolt Babak wrote:
>>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
AnonimoVeneziano wrote:
> 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,
--
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]
AnonimoVeneziano wrote:
> 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
>
>
> AnonimoVeneziano wrote:
>
>> 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/
>>
>
>
> -
> 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/
>