lkml.org 
[lkml]   [2004]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRE: spurious 8259A interrupt
    Date
    From
    > 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/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.037 / U:119.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site