spurious 8259A interrupt: IRQ7

spurious 8259A interrupt: IRQ7

[Lee Revell]

I get this message occasionally on both my machines.  I googled and saw
some references to this message on 2.4 but nothing for 2.6.  Some of the
references were to APIC, which I don't have enabled.

Both machines are using VIA chipsets and display the "VIA IRQ fixup"
message on boot.  I think this behavior started about the same time that
message started to appear.

On both machines the parallel port is disabled in the BIOS and there's
nothing on IRQ7.

Lee

Re: spurious 8259A interrupt: IRQ7

[Bjorn Helgaas]

On Thu, 2005-04-14 at 13:11 -0400, Lee Revell wrote:
> I get this message occasionally on both my machines.  I googled and saw
> some references to this message on 2.4 but nothing for 2.6.  Some of the
> references were to APIC, which I don't have enabled.
> 
> Both machines are using VIA chipsets and display the "VIA IRQ fixup"
> message on boot.  I think this behavior started about the same time that
> message started to appear.

The VIA IRQ fixup in 2.6.11 is broken.  It works for some, but
not all boxes with VIA hardware.

There's a fix in 2.6.12-rc2-mm3.  Actually, I doubt that it will
help you, though -- the 2.6.11 breakage is such that some machines
that need the fixup don't get it (and don't print the "VIA IRQ
fixup message").

Re: spurious 8259A interrupt: IRQ7

[Lee Revell]

On Thu, 2005-04-14 at 14:43 -0600, Bjorn Helgaas wrote:
> On Thu, 2005-04-14 at 13:11 -0400, Lee Revell wrote:
> > I get this message occasionally on both my machines.  I googled and saw
> > some references to this message on 2.4 but nothing for 2.6.  Some of the
> > references were to APIC, which I don't have enabled.
> > 
> > Both machines are using VIA chipsets and display the "VIA IRQ fixup"
> > message on boot.  I think this behavior started about the same time that
> > message started to appear.
> 
> The VIA IRQ fixup in 2.6.11 is broken.  It works for some, but
> not all boxes with VIA hardware.
> 
> There's a fix in 2.6.12-rc2-mm3.  Actually, I doubt that it will
> help you, though -- the 2.6.11 breakage is such that some machines
> that need the fixup don't get it (and don't print the "VIA IRQ
> fixup message").
> 

Is the VIA IRQ fixup related to the "spurious interrupts" messages in
any way?  Googling the 2.4 threads on the issue gave me the impression
that it's related to broken hardware.  I think excessive disk activity
might trigger it.

Anyway it's low priority as the message appears to be completely
harmless.

Lee

Re: spurious 8259A interrupt: IRQ7

[Bjorn Helgaas]

On Thu, 2005-04-14 at 16:56 -0400, Lee Revell wrote:
> Is the VIA IRQ fixup related to the "spurious interrupts" messages in
> any way?  Googling the 2.4 threads on the issue gave me the impression
> that it's related to broken hardware.  I think excessive disk activity
> might trigger it.

If you need the VIA IRQ fixup and don't have it, I would expect
some interrupt to be routed to the wrong IRQ.  That might give
you a "spurious interrupt" on the wrong IRQ, but your device would
probably just not work at all.

Re: spurious 8259A interrupt: IRQ7

[Jesper Juhl]

On 4/14/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Thu, 2005-04-14 at 16:56 -0400, Lee Revell wrote:
> > Is the VIA IRQ fixup related to the "spurious interrupts" messages in
> > any way?  Googling the 2.4 threads on the issue gave me the impression
> > that it's related to broken hardware.  I think excessive disk activity
> > might trigger it.
> 
> If you need the VIA IRQ fixup and don't have it, I would expect
> some interrupt to be routed to the wrong IRQ.  That might give
> you a "spurious interrupt" on the wrong IRQ, but your device would
> probably just not work at all.
> 

For what it's worth I'll chime in with my own info on this subject.

I also see the 
   spurious 8259A interrupt: IRQ7.
messages from time to time. Actually I got one just a little while ago : 
   $ dmesg | grep spurious
   [18994.222451] spurious 8259A interrupt: IRQ7.
The system seems to be in good shape - it has never caused me any
actual trouble.

As for the via irq fixup I see this :
   $ dmesg | grep -i fixup
   [   74.629393] PCI: Via PIC IRQ fixup for 0000:00:09.0, from 255 to 3

The hardware is a ASUS A7M266 mobo with a AMD Athlon (t-bird) 1.4GHz CPU.

The kernel is 2.6.12-rc4-mm2 : 
   $ uname -a
   Linux dragon 2.6.12-rc4-mm2 #2 Mon May 16 18:14:13 CEST 2005 i686
unknown unknown GNU/Linux

I've seen some references to APIC for this issue, so here are the APIC
related settings in my .config :

   juhl@dragon:~/download/kernel/linux-2.6.12-rc4-mm2$ grep -i APIC .config
   CONFIG_X86_GOOD_APIC=y
   # CONFIG_X86_UP_APIC is not set


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

spurious 8259A interrupt: IRQ7

[Jiri Slaby]

Hello,

I have this problem with irq 7. There are many ERR interrupts as you can see in
the table below.
Count of errorneous is similar to count of radeon interrupts (since start of
system).
It appears in all kernels I tried (since 2.6.11.7).
           CPU0       
  0:     367164          XT-PIC  timer
  1:       2397          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:       5355          XT-PIC  ATI IXP, eth0
  8:          1          XT-PIC  rtc
  9:        163          XT-PIC  acpi
 10:      25595          XT-PIC  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
 11:      85385          XT-PIC  radeon@pci:0000:01:05.0
 12:       4991          XT-PIC  i8042
 14:       8576          XT-PIC  ide0
 15:      12774          XT-PIC  ide1
NMI:          0 
LOC:     367136 
ERR:      82119
MIS:          0

without running X, there is no ERR (and also no irq 11).
Card:
01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [Radeon Mobility 9100IGP] (prog-if 00 [VGA])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 1902
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min), Cache Line Size 10
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
        Region 1: I/O ports at d000 [size=256]
        Region 2: Memory at fda00000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fd900000 [disabled] [size=128K]
        Capabilities: [58] AGP version 3.0
                Status: RQ=256 Iso- ArqSz=0 Cal=7 SBA+ ITACoh- GART64- HTrans- 64bit+ FW+ AGP3+ Rate=x4,x8
                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

regards,
--
Jiri Slaby         www.fi.muni.cz/~xslaby
~\-/~      jirislaby@gmail.com      ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E

spurious 8259A interrupt: IRQ7

[Jiri Slaby]

Cc: benh@kernel.crashing.org

>Hello,
>
>I have this problem with irq 7. There are many ERR interrupts as you can see in
>the table below.
>Count of errorneous is similar to count of radeon interrupts (since start of
>system).
>It appears in all kernels I tried (since 2.6.11.7).
>           CPU0       
>  0:     367164          XT-PIC  timer
>  1:       2397          XT-PIC  i8042
>  2:          0          XT-PIC  cascade
>  5:       5355          XT-PIC  ATI IXP, eth0
>  8:          1          XT-PIC  rtc
>  9:        163          XT-PIC  acpi
> 10:      25595          XT-PIC  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
> 11:      85385          XT-PIC  radeon@pci:0000:01:05.0
> 12:       4991          XT-PIC  i8042
> 14:       8576          XT-PIC  ide0
> 15:      12774          XT-PIC  ide1
>NMI:          0 
>LOC:     367136 
>ERR:      82119
>MIS:          0
>
>without running X, there is no ERR (and also no irq 11).
>Card:
>01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [Radeon Mobility 9100IGP] (prog-if 00 [VGA])
>        Subsystem: ASUSTeK Computer Inc.: Unknown device 1902
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
>        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 64 (2000ns min), Cache Line Size 10
>        Interrupt: pin A routed to IRQ 11
>        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
>        Region 1: I/O ports at d000 [size=256]
>        Region 2: Memory at fda00000 (32-bit, non-prefetchable) [size=64K]
>        Expansion ROM at fd900000 [disabled] [size=128K]
>        Capabilities: [58] AGP version 3.0
>                Status: RQ=256 Iso- ArqSz=0 Cal=7 SBA+ ITACoh- GART64- HTrans- 64bit+ FW+ AGP3+ Rate=x4,x8
>                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8
>        Capabilities: [50] Power Management version 2
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
>regards,
>--
>Jiri Slaby         www.fi.muni.cz/~xslaby
>~\-/~      jirislaby@gmail.com      ~\-/~
>B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: spurious 8259A interrupt: IRQ7

[Jan Engelhardt]

>Cc: benh@kernel.crashing.org
>
>>Hello,
>>
>>  0:     367164          XT-PIC  timer

>>01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [Radeon Mobility 9100IGP] (prog-if 00 [VGA])
>>        Subsystem: ASUSTeK Computer Inc.: Unknown device 1902

You seem to have APIC disabled?



Jan Engelhardt
-- 

Re: spurious 8259A interrupt: IRQ7

[Jiri Slaby]

Jan Engelhardt wrote:
>>>  0:     367164          XT-PIC  timer
>
>>>01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [Radeon Mobility 9100IGP] (prog-if 00 [VGA])
>>>        Subsystem: ASUSTeK Computer Inc.: Unknown device 1902
>
>You seem to have APIC disabled?
Nope. There are also lines
LOC:     367136
and
MIS:          0
which are printed only with (io)apic enabled.

$ dmesg|grep -i apic
Found and enabled local APIC!
mapped APIC to ffffd000 (fee00000)
$ grep APIC config 
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

dmesg and config are here (I forgot to attach before):
http://www.fi.muni.cz/~xslaby/sklad/{dmesg,config}

regards,
--
Jiri Slaby         www.fi.muni.cz/~xslaby
~\-/~      jirislaby@gmail.com      ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: spurious 8259A interrupt: IRQ7

[Jiri Slaby]

>Hello,
>
>I have this problem with irq 7. There are many ERR interrupts as you can see in
>the table below.
>Count of errorneous is similar to count of radeon interrupts (since start of
>system).
>It appears in all kernels I tried (since 2.6.11.7).
>           CPU0       
>  0:     367164          XT-PIC  timer
>  1:       2397          XT-PIC  i8042
>  2:          0          XT-PIC  cascade
>  5:       5355          XT-PIC  ATI IXP, eth0
>  8:          1          XT-PIC  rtc
>  9:        163          XT-PIC  acpi
> 10:      25595          XT-PIC  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
> 11:      85385          XT-PIC  radeon@pci:0000:01:05.0
> 12:       4991          XT-PIC  i8042
> 14:       8576          XT-PIC  ide0
> 15:      12774          XT-PIC  ide1
>NMI:          0 
>LOC:     367136 
>ERR:      82119
>MIS:          0
>
>without running X, there is no ERR (and also no irq 11).
>Card:
>01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [Radeon Mobility 9100IGP] (prog-if 00 [VGA])
>        Subsystem: ASUSTeK Computer Inc.: Unknown device 1902
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
>        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 64 (2000ns min), Cache Line Size 10
>        Interrupt: pin A routed to IRQ 11
>        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
>        Region 1: I/O ports at d000 [size=256]
>        Region 2: Memory at fda00000 (32-bit, non-prefetchable) [size=64K]
>        Expansion ROM at fd900000 [disabled] [size=128K]
>        Capabilities: [58] AGP version 3.0
>                Status: RQ=256 Iso- ArqSz=0 Cal=7 SBA+ ITACoh- GART64- HTrans- 64bit+ FW+ AGP3+ Rate=x4,x8
>                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8
>        Capabilities: [50] Power Management version 2
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Me again, I found out, that if I load parport_pc (its irq handler takes
care of irq7, i guess) earlier than X starts, there is no line spurious IRQ7.
Does this mean badly written radeon int handler or somewhat?

thanks,
--
Jiri Slaby         www.fi.muni.cz/~xslaby
~\-/~      jirislaby@gmail.com      ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: spurious 8259A interrupt: IRQ7

[Petr Vandrovec]

On  8 Jul 02 at 12:05, Tomas Szepe wrote:
> > I have read through quite a few mailing lists and other sources but
> > can't find an adequate solution. One solution I found was to turn off
> > Local APIC support and IO-APIC support in the kernel, which I tried and
> > it worked, but I'd rather not do this. I realise the error isn't of a
> > huge concern but it's still annoying having it appear everytime the
> > machine boots up.
> 
> Your fix is to just realize that this is a mere warning -- Nothing's
> wrong with your setup.
> 
> If you dig out a thread that came through here abt. two months ago,
> you'll find a comprehensive explanation of what the message means.

Fortunately... since kernel HZ changed to 1000Hz, I have about two these
spurious interrupts delivered to the CPU on my A7V each second. Fortunately 
they are always really spurious, not misdelivered other interrupts, but 
seeing values like 10000 in ERR field in /proc/interrupts is something new 
to me ;-) Maybe VIA or AMD should really clarify what's the problem.
                                                            Petr Vandrovec
                                                            

spurious 8259A interrupt: IRQ7

[Patrick Clohessy]

Hi

I was just wondering if anyone could help me solve a problem I'm having.
I have installed red hat 7.3 with kernel version 2.4.18 on an AMD Duron
1100 with a ASUS A7V133-C Motherboard, 32MB TNT2 and a 20 GIG Maxtor
Viper HD. Whenever the machine boots up, the following error appears :

spurious 8259A interrupt: IRQ7

I have read through quite a few mailing lists and other sources but
can't find an adequate solution. One solution I found was to turn off
Local APIC support and IO-APIC support in the kernel, which I tried and
it worked, but I'd rather not do this. I realise the error isn't of a
huge concern but it's still annoying having it appear everytime the
machine boots up.

Any help will be greatly appreciated.

Thanks


--
Patrick Clohessy
Curtin University of Technology
School of Computing
Tel: +61 8 9266 2986
email: pat@cs.curtin.edu.au

Re: spurious 8259A interrupt: IRQ7

[jbradford]

Hi,

> I was just wondering if anyone could help me solve a problem I'm having.
> I have installed red hat 7.3 with kernel version 2.4.18 on an AMD Duron
> 1100 with a ASUS A7V133-C Motherboard, 32MB TNT2 and a 20 GIG Maxtor
> Viper HD. Whenever the machine boots up, the following error appears :
> 
> spurious 8259A interrupt: IRQ7
> 
> I have read through quite a few mailing lists and other sources but
> can't find an adequate solution. One solution I found was to turn off
> Local APIC support and IO-APIC support in the kernel, which I tried and
> it worked, but I'd rather not do this. I realise the error isn't of a
> huge concern but it's still annoying having it appear everytime the
> machine boots up.
> 
> Any help will be greatly appreciated.

Why not just comment out the line in the kernel source that prints the error?  I know it sounds stupid, but it will solve your problem :-).

John.

Re: spurious 8259A interrupt: IRQ7

[Tomas Szepe]

> I have read through quite a few mailing lists and other sources but
> can't find an adequate solution. One solution I found was to turn off
> Local APIC support and IO-APIC support in the kernel, which I tried and
> it worked, but I'd rather not do this. I realise the error isn't of a
> huge concern but it's still annoying having it appear everytime the
> machine boots up.

Your fix is to just realize that this is a mere warning -- Nothing's
wrong with your setup.

If you dig out a thread that came through here abt. two months ago,
you'll find a comprehensive explanation of what the message means.

T.