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
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 === )
\ ._|_. /
^-_ _-^
???
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
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: [email protected]
> [mailto:[email protected]]On Behalf Of szonyi calin
> Sent: Wednesday November 28, 2001 9:59 AM
> To: [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
----- Original Message -----
From: "Wouter van Bommel" <[email protected]>
To: "'szonyi calin'" <[email protected]>; <[email protected]>
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 <[email protected]>
| MSc CSE student, department of Computing Science
| Ume? University, Sweden
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of szonyi calin
> > Sent: Wednesday November 28, 2001 9:59 AM
> > To: [email protected]
> > 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
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
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.
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: [email protected] (personal) |
| .|. [email protected] (professional) |
| /V\ |
| // \\ UIN: 116043354 Homepage: http://www.piterpunk.hpg.com.br |
| /( )\ |
| ^`~'^ ----> Slackware Linux - The Best One! <---- |
| #105432 |
`-------------------------------------------------------------------'
"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)
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.
----- Original Message -----
From: "Gunther Mayer" <[email protected]>
To: <[email protected]>
Cc: "Chris Meadors" <[email protected]>; "Martin Eriksson"
<[email protected]>; <[email protected]>; <[email protected]>
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 <[email protected]>
| MSc CSE student, department of Computing Science
| Ume? University, Sweden
"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 ...