Date: Fri, 19 Mar 2004 13:06:10 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Robert_Hentosh@Dell.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: spurious 8259A interrupt
Message-ID: <20040319130609.GE2650@mail.shareable.org>
References: <6C07122052CB7749A391B01A4C66D31E014BEA49@ausx2kmps304.aus.amer.dell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6C07122052CB7749A391B01A4C66D31E014BEA49@ausx2kmps304.aus.amer.dell.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1422
Lines: 34

Robert_Hentosh@Dell.com wrote:
> >  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

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

That reminds me: why does Linux mask the IRQ anyway?

Why doesn't it simply call the handler functions, and then send EOI to
the PIC with no unmasking?

For those rare occasions when an interrupt handler wants to re-enable
interrupts (sti), _then_ it could mask the interrupt that called the handler.

Why wouldn't that work?

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