Spurious 8259A interrupt: IRQ7 ????

Spurious 8259A interrupt: IRQ7 ????

[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

Re: Spurious 8259A interrupt: IRQ7 ????

[David D. Hagood]

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.

Re: Spurious 8259A interrupt: IRQ7 ????

[Coax]

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 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/
>

Re: Spurious 8259A interrupt: IRQ7 ????

[Alan]

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

Re: Spurious 8259A interrupt: IRQ7 ????

[Tupshin Harper]

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

Re: Spurious 8259A interrupt: IRQ7 ????

[Paul]

Tupshin Harper <tupshin@tupshin.com>, 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
set@pobox.com

Re: Spurious 8259A interrupt: IRQ7 ????

[Ville Hallivuori]

> 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][vph@iki.fi][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]

Re: Spurious 8259A interrupt: IRQ7 ????

[Pavel Janík]

   From: Ville Hallivuori <vph@iki.fi>
   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

Re: Spurious 8259A interrupt: IRQ7 ????

[AnonimoVeneziano]

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

Re: Spurious 8259A interrupt: IRQ7 ????

[AnonimoVeneziano]

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

Re: Spurious 8259A interrupt: IRQ7 ????

[Richard B. Johnson]

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.

Re: Spurious 8259A interrupt: IRQ7 ????

[Tom Vier]

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 <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: Spurious 8259A interrupt: IRQ7 ????

[Zsolt Babak]

> 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 --

Re: Spurious 8259A interrupt: IRQ7 ????

[Herman Oosthuysen]

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.

Re: Spurious 8259A interrupt: IRQ7 ????

[AnonimoVeneziano]

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 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/
>

Re: Spurious 8259A interrupt: IRQ7 ????

[Herman Oosthuysen]

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: Herman@AerospaceSoftware.com
E-mail: Herman@ARMdimension.com


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 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/
>>
> 
> 
> -
> 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/
>