content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: spurious 8259A interrupt
Date: Tue, 16 Mar 2004 14:32:48 -0600
Message-ID: <6C07122052CB7749A391B01A4C66D31E014BEA49@ausx2kmps304.aus.amer.dell.com>
Thread-Topic: spurious 8259A interrupt
Thread-Index: AcQLjEFmUsX57s12RxCwRj6gBiKbjQAAEJTw
From: Robert_Hentosh@Dell.com
To: fleury@cs.auc.dk, linux-kernel@vger.kernel.org
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2100
Lines: 55

> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> Emmanuel Fleury
> Sent: Tuesday, March 16, 2004 12:36 PM
> 
> 
> Hi,
> 
> I noticed today that I had several "spurious 8259A interrupt":
> 
> Dec 20 15:02:45 hermes vmunix: spurious 8259<3>[drm:radeon_cp_init]

  :: SNIP ::

So a co-worker of mine (Stuart Hayes) did some digging into this issue.
What he found after putting a scope on the system was, in our situation
it was harmless:

The problem was actually caused by another IRQ (in our instance it was
IRQ10 associated with a gigabit NIC). The following steps took place:

>  IRQ10 asserted
>  INTACK cycle lets PIC deliver vector to processor
>  processor masks IRQ10 in PIC
>  processor sends EOI command to PIC
>  processor reads a status register in the NIC, which causes IRQ10 to
be deasserted
>  processor unmasks IRQ10 in PIC
>
> Sometimes the processor would unmask IRQ10 almost immediately after
reading the status
> register in the NIC, which results in IRQ10 being unmasked before the
IRQ10 signal has
> finished going high.  This causes the PIC to think that there is
another IRQ10, but, 
> by the time the processor asks for the vector, IRQ10 is no longer
asserted.

The PIC defaults to IRQ7 because of its design, when IRQ10 was already
cleared. Sticking delays in is not viable in a generic ISR routing.  A
possible fix to this issue would be to issue the EOI after the read to
the status register on the NIC, and I see some documentation on the PIC
that actually suggests that this is the way to service an interrupt.
This seemed like a risky change, since sending the EOI and using the
mask has been in use for some time and the change would effect all
devices using interrupts.

The spurious IRQ performance impact is negligible since it is logged
only once per IRQ at most.

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