Re: 'spurious 8259A interrupt: IRQ7'

Re: 'spurious 8259A interrupt: IRQ7'

[Alex Davis]

I don't have a tulip card in my machine, and I still
have the problem. I only have spurious ints. with my
Athlon-based systems: my Intel-based machines don't
exhibit them. I think we should compile a list of boards
that have the problem and try to find some commonality.

-Alex

Martin A. Brooks" schrieb:
> 
> > As far as I remember this was talked about earlier. Different mobos,
> > chipsets, processor brands, but always IRQ 7. /me wonders.
> 
> In my research before posting, a common thread seemed to be the presence of
> a tulip card in the machine.  Has anyone seen this on a non-tulip box?
> 


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: 'spurious 8259A interrupt: IRQ7'

[Peter Bornemann]

On Tue, 27 Nov 2001, Alex Davis wrote:

> I think we should compile a list of boards
> that have the problem

If You are collecting examples:
I am seeing it on a regular base during boot-up, sometimes also later on.
I have an  Athlon 700 on an Asus K7V Mobo with VIA Apollo chipset and 512
MB RAM. Otherwise, the box is  rock solid.

Hope this helps

Peter B

          .         .
          |\_-^^^-_/|
          / (|)_(|) \
         ( === X === )
          \  ._|_.  /
           ^-_   _-^
              °°°

Re: 'spurious 8259A interrupt: IRQ7'

[szonyi calin]

Hi
Cx 486,  no pci, no network card, same message.
>From my experience in PC hardware i know that irq 7 is
usually asigned to the parallel port.
I know a windoze box which didn't print until i set up
in bios that paralel port has irq7.

Bye

=====
*********************************************************
                Désolé, un problème s'est produit : 
                 *  votre signature ne peut pas comporter 
                 plus de 600 caractères ni occuper plus de 
                 sept lignes. 
Another way to say: Welcome to Yahoo! ^^^
**********************************************************

__________________________________________________________
Obtenez votre adresse @yahoo.ca gratuite et en français !
courriel.yahoo.ca

RE: 'spurious 8259A interrupt: IRQ7'

[Wouter van Bommel]

I also see this messages on various machines each with different hardware.
I see it on 1 cpu Athlon machines, but also on 2 CPU pentium III machines.

- Wouter

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of szonyi calin
> Sent: Wednesday November 28, 2001 9:59 AM
> To: linux-kernel@vger.kernel.org
> Subject: Re: 'spurious 8259A interrupt: IRQ7'
>
>
> Hi
> Cx 486,  no pci, no network card, same message.
> >From my experience in PC hardware i know that irq 7 is
> usually asigned to the parallel port.
> I know a windoze box which didn't print until i set up
> in bios that paralel port has irq7.
>
> Bye
>
> =====
> *********************************************************
>                 Désolé, un problème s'est produit :
>                  *  votre signature ne peut pas comporter
>                  plus de 600 caractères ni occuper plus de
>                  sept lignes.
> Another way to say: Welcome to Yahoo! ^^^
> **********************************************************
>
> __________________________________________________________
> Obtenez votre adresse @yahoo.ca gratuite et en français !
> courriel.yahoo.ca
> -
> 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'

[Martin Eriksson]

----- Original Message -----
From: "Wouter van Bommel" <wvanbommel@jasongeo.com>
To: "'szonyi calin'" <caszonyi@yahoo.com>; <linux-kernel@vger.kernel.org>
Sent: Wednesday, November 28, 2001 10:31 AM
Subject: RE: 'spurious 8259A interrupt: IRQ7'


> I also see this messages on various machines each with different hardware.
> I see it on 1 cpu Athlon machines, but also on 2 CPU pentium III machines.

Now here is a strange thing: I see it in my brothers ADSL linux router
syslog *before* they moved it to another place in their room two weeks ago.
Now it never appears, and before it appeared about once a day. They are
using 2.4.13 with ext3.

I'm starting to believe it has something to do with the parallel port being
unconnected, thus sending random signals to the mobo causing an interrupt?
If this is the case it is very possible that it has to do with correct
grounding also...

_____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  MSc CSE student, department of Computing Science
|  Umeå University, Sweden

> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of szonyi calin
> > Sent: Wednesday November 28, 2001 9:59 AM
> > To: linux-kernel@vger.kernel.org
> > Subject: Re: 'spurious 8259A interrupt: IRQ7'
> >
> >
> > Hi
> > Cx 486,  no pci, no network card, same message.
> > >From my experience in PC hardware i know that irq 7 is
> > usually asigned to the parallel port.
> > I know a windoze box which didn't print until i set up
> > in bios that paralel port has irq7.
> >
> > Bye

Re: 'spurious 8259A interrupt: IRQ7'

[Chris Meadors]

On Wed, 28 Nov 2001, Martin Eriksson wrote:

> I'm starting to believe it has something to do with the parallel port being
> unconnected, thus sending random signals to the mobo causing an interrupt?
> If this is the case it is very possible that it has to do with correct
> grounding also...

Actually I believe way back there was a discussion about this same
message, Alan Cox said he thought it was caused by bad parallel ports.

That said I see it on 2 Athlon boxes with VIA chipsets.  One I had never
seen the message until I removed the parallel port QuickCam I had hooked
up.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..."                         --David Lynch, Twin Peaks

Re: 'spurious 8259A interrupt: IRQ7'

[Richard B. Johnson]

On Wed, 28 Nov 2001, Chris Meadors wrote:

> On Wed, 28 Nov 2001, Martin Eriksson wrote:
> 
> > I'm starting to believe it has something to do with the parallel port being
> > unconnected, thus sending random signals to the mobo causing an interrupt?
> > If this is the case it is very possible that it has to do with correct
> > grounding also...
> 
> Actually I believe way back there was a discussion about this same
> message, Alan Cox said he thought it was caused by bad parallel ports.
> 
> That said I see it on 2 Athlon boxes with VIA chipsets.  One I had never
> seen the message until I removed the parallel port QuickCam I had hooked
> up.
> 

IRQ7 is usually connected to the parallel port. If there is no driver
installed, that expects interrupts, you could end up with this
annoying message because the printer status bits are all ORed into
that IRQ line. You can disable this with software, though, and it
might be a good idea.

          outb(0, BASE+2);

... where BASE is 0x278, 0x378, 0x3bc, etc.. the printer ports.

Also, a catch-all for confused interrupt controllers is IRQ7. Even
without a parallel port, you can still get an occasional spurious
interrupt. I think the kernel should have an interrupt handler for
this interrupt that does nothing except ACK the interrupt and
keep its mouth shut.  The request_irq() procedure should ignore
the fact that it is "in use", and let any driver have it without
sharing it.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: 'spurious 8259A interrupt: IRQ7'

[Piter Punk]

Richard B. Johnson wrote:

>
> IRQ7 is usually connected to the parallel port. If there is no driver
> installed, that expects interrupts, you could end up with this
> annoying message because the printer status bits are all ORed into
> that IRQ line. You can disable this with software, though, and it
> might be a good idea.
> 
>           outb(0, BASE+2);
> 
> ... where BASE is 0x278, 0x378, 0x3bc, etc.. the printer ports.


Hmmmm. I have a driver installed! I use a printer in my parallel port and i 
need lp module is installed.

But... i am go to see if this message appears only on boot (before i load 
the module) or appears all time...

 
> Also, a catch-all for confused interrupt controllers is IRQ7. Even
> without a parallel port, you can still get an occasional spurious
> interrupt. I think the kernel should have an interrupt handler for
> this interrupt that does nothing except ACK the interrupt and
> keep its mouth shut.  The request_irq() procedure should ignore
> the fact that it is "in use", and let any driver have it without
> sharing it.

-- 
   ____________
  / Piter PUNK \_____________________________________________________
|                                                                   |
|      |        E-Mail: piterpk@terra.com.br         (personal)     |
|     .|.               roberto.freires@gds-corp.com (professional) |
|     /V\                                                           |
|    // \\      UIN: 116043354  Homepage: www.piterpunk.hpg.com.br  |
|   /(   )\                                                         |
|    ^`~'^         ----> Slackware Linux - The Best One! <----      |
|   #105432                                                         |
`-------------------------------------------------------------------'

Re: 'spurious 8259A interrupt: IRQ7' -> read the 8259 datasheet !

[Gunther Mayer]

"Richard B. Johnson" wrote:
> 
> On Wed, 28 Nov 2001, Chris Meadors wrote:
> 
> > On Wed, 28 Nov 2001, Martin Eriksson wrote:

...
... rumours deleted (e.g. "printer status bits are all ORed into irq7")
...

>From "Harris Semiconductor 82C59A Interrupt Controller Datasheet":
  If no interrupt request is present at step 4 of either sequence
  (i.e., the request was too short in duration), the 82C59A will
  issue an interrupt level 7. 

1. The irq controller sees an interrupt.
2. The irq controller signals "there is _some_ interrupt" to the cpu.
3. The CPU acks via INTA
4. The irq controller looks if the irq is still there
   (and signals IRQ7 if the line is no longer active).

You have some device which doesn't keep the IRQ raised long enough !
(or the CPU doesn't service the irq for a too long time and the 
 edge triggered irq is de-asserted or even serviced by a polling routine)

Re: 'spurious 8259A interrupt: IRQ7' -> read the 8259 datasheet !

[Richard B. Johnson]

On Fri, 30 Nov 2001, Gunther Mayer wrote:

> "Richard B. Johnson" wrote:
> > 
> > On Wed, 28 Nov 2001, Chris Meadors wrote:
> > 
> > > On Wed, 28 Nov 2001, Martin Eriksson wrote:
> 
> ...
> ... rumours deleted (e.g. "printer status bits are all ORed into irq7")
> ...
> 
> >From "Harris Semiconductor 82C59A Interrupt Controller Datasheet":
>   If no interrupt request is present at step 4 of either sequence
>   (i.e., the request was too short in duration), the 82C59A will
>   issue an interrupt level 7. 
> 
> 1. The irq controller sees an interrupt.
> 2. The irq controller signals "there is _some_ interrupt" to the cpu.
> 3. The CPU acks via INTA
> 4. The irq controller looks if the irq is still there
>    (and signals IRQ7 if the line is no longer active).
> 
> You have some device which doesn't keep the IRQ raised long enough !
> (or the CPU doesn't service the irq for a too long time and the 
>  edge triggered irq is de-asserted or even serviced by a polling routine)
> -

In the first place I HAVE not only read the data-sheet, but probably
was one of the first to report the affect when first observed in
the days of XT machines, before there was a second cascaded controller.

If the effect was caused by the transient condition you describe, then
the second controller would also suffer from the same problem, i.e.,
its "IRQ7" is really IRQ15 when cascaded.

The problems with "spurious IRQ7" reared its head when the new
boards and cards became available with CMOS inputs with weak and/or
no pull-ups. If you leave a connector off the printer port, the
status bits will float and generate interrupts on IRQ7. You can
stop this, as previously taught, by disabling the IRQ enable
by writing bit 4 of the control-port (offset 1) to zero. You do
this on all known printer ports and you no longer get the kernel
messages.

So, before you issue another "rumors deleted" know-it-all retort,
observe that you can "mysteriously" stop the problem by mucking
with the printer control port. This certainly seems to disprove
your INTA theory.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: 'spurious 8259A interrupt: IRQ7' -> read the 8259 datasheet !

[Martin Eriksson]

----- Original Message -----
From: "Gunther Mayer" <Gunther.Mayer@t-online.de>
To: <root@chaos.analogic.com>
Cc: "Chris Meadors" <clubneon@hereintown.net>; "Martin Eriksson"
<nitrax@giron.wox.org>; <linux-kernel@vger.kernel.org>; <martin@jtrix.com>
Sent: Friday, November 30, 2001 8:28 PM
Subject: Re: 'spurious 8259A interrupt: IRQ7' -> read the 8259 datasheet !


> "Richard B. Johnson" wrote:
> >
> > On Wed, 28 Nov 2001, Chris Meadors wrote:
> >
> > > On Wed, 28 Nov 2001, Martin Eriksson wrote:
>
> ...
> ... rumours deleted (e.g. "printer status bits are all ORed into irq7")
> ...
>
> >From "Harris Semiconductor 82C59A Interrupt Controller Datasheet":
>   If no interrupt request is present at step 4 of either sequence
>   (i.e., the request was too short in duration), the 82C59A will
>   issue an interrupt level 7.

Uhmm... call me slow, but I don't get it 100%... so this message has NOTHING
to do with the LPT IRQ7? It just signals this because IRQ7 is the lowest
priority IRQ on the 8259A?

>
> 1. The irq controller sees an interrupt.
> 2. The irq controller signals "there is _some_ interrupt" to the cpu.
> 3. The CPU acks via INTA
> 4. The irq controller looks if the irq is still there
>    (and signals IRQ7 if the line is no longer active).

Umm.. so again.. this means that the IRQ is not held long enough for the PIC
to actually recognize *what* IRQ was asserted?

>
> You have some device which doesn't keep the IRQ raised long enough !
> (or the CPU doesn't service the irq for a too long time and the
>  edge triggered irq is de-asserted or even serviced by a polling routine)

Thanks a bunch for clearing this up (this far)!!

When we get a firm indication on the 'problem', could the "spurious 8259A
interrupt" message be de-obfuscated into something less unsettling?

PS. Real Men (tm) never reads the datasheets!

_____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  MSc CSE student, department of Computing Science
|  Umeå University, Sweden

Re: 'spurious 8259A interrupt: IRQ7' -> read the 8259 datasheet !

[Gunther Mayer]

"Richard B. Johnson" wrote:
> 
> On Fri, 30 Nov 2001, Gunther Mayer wrote:
> 
> > "Richard B. Johnson" wrote:
> > >
> > > On Wed, 28 Nov 2001, Chris Meadors wrote:
> > >
> > > > On Wed, 28 Nov 2001, Martin Eriksson wrote:
> >
> > ...
> > ... rumours deleted (e.g. "printer status bits are all ORed into irq7")
> > ...
> >
> > >From "Harris Semiconductor 82C59A Interrupt Controller Datasheet":
> >   If no interrupt request is present at step 4 of either sequence
> >   (i.e., the request was too short in duration), the 82C59A will
> >   issue an interrupt level 7.
> >
> > 1. The irq controller sees an interrupt.
> > 2. The irq controller signals "there is _some_ interrupt" to the cpu.
> > 3. The CPU acks via INTA
> > 4. The irq controller looks if the irq is still there
> >    (and signals IRQ7 if the line is no longer active).
> >
> > You have some device which doesn't keep the IRQ raised long enough !
> > (or the CPU doesn't service the irq for a too long time and the
> >  edge triggered irq is de-asserted or even serviced by a polling routine)
> > -
> 
> In the first place I HAVE not only read the data-sheet, but probably
> was one of the first to report the affect when first observed in
> the days of XT machines, before there was a second cascaded controller.
> 
> If the effect was caused by the transient condition you describe, then
> the second controller would also suffer from the same problem, i.e.,
> its "IRQ7" is really IRQ15 when cascaded.

The slave could ignore T3-T7 when it detects a spurious irq and
signal IRQ7 to the CPU nevertheless !

> 
> The problems with "spurious IRQ7" reared its head when the new
> boards and cards became available with CMOS inputs with weak and/or
> no pull-ups. If you leave a connector off the printer port, the
> status bits will float and generate interrupts on IRQ7. You can
> stop this, as previously taught, by disabling the IRQ enable
> by writing bit 4 of the control-port (offset 1) to zero. You do
> this on all known printer ports and you no longer get the kernel
> messages.
> 
> So, before you issue another "rumors deleted" know-it-all retort,
> observe that you can "mysteriously" stop the problem by mucking
> with the printer control port. This certainly seems to disprove
> your INTA theory.

Get some data sheet about the parallel port to see:
"Bit 4: A 1 in this position allows an interrupt to occur when nACK changes from low to high."
So the status bits are _not_ ORed.

I agree, a floating nACK would provoke IRQ7 (or IRQ5 when configured for this).

On the parport list a user reports he gets some spurious irq7 on probing a PCI
card configured to IRQ12 ! So this card seems to trigger the 8259 generated IRQ7,
which proves the case described in the 8259 datasheet happens in reality.

In summary IRQ7 can be raised:
a) by parallel port due to floating nACK
b) by 8259 itself on some transient condition (this could be further be proved by
   suspending INTA and forcefully raising and releasing an irq, don't know if this is feasible)

Your proposition to set Bit4=0 would allow to rule out case b), of course.
It seems the inital reporter can reproduce the conditions ...