[PATCH RT] add pending in fasteoi for IOAPIC hack

[PATCH RT] add pending in fasteoi for IOAPIC hack

[Steven Rostedt]

The IOAPIC hack that does a level=>edge to mask does not disable
interrupts. So we can receive interrupts when masked, and this means
that we can miss interrupts that arrive when the thread is handling
them.

This patch adds the "IRQ_PENDING" logic of the edge irqs to be
able to catch interrupts coming in when supposably "masked".

Signed-off-by: Steven Rostedt <srostedt@redhat.com>

Index: linux-2.6.21-rt-hack/kernel/irq/chip.c
===================================================================
--- linux-2.6.21-rt-hack.orig/kernel/irq/chip.c
+++ linux-2.6.21-rt-hack/kernel/irq/chip.c
@@ -398,8 +398,10 @@ handle_fasteoi_irq(unsigned int irq, str

 	spin_lock(&desc->lock);

-	if (unlikely(desc->status & IRQ_INPROGRESS))
+	if (unlikely(desc->status & IRQ_INPROGRESS)) {
+		desc->status |= IRQ_PENDING;
 		goto out;
+	}

 	desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
 	kstat_cpu(cpu).irqs[irq]++;

Re: [PATCH RT] add pending in fasteoi for IOAPIC hack

[Jon Masters]

On Wed, 2007-12-12 at 15:41 -0500, Steven Rostedt wrote:
> The IOAPIC hack that does a level=>edge to mask does not disable
> interrupts. So we can receive interrupts when masked, and this means
> that we can miss interrupts that arrive when the thread is handling
> them.
> 
> This patch adds the "IRQ_PENDING" logic of the edge irqs to be
> able to catch interrupts coming in when supposably "masked".

ACK on all of these. I've been using them internally for a bit in
pursuit of a later problem. Additionally, I am currently reworking the
level->edge->level hack because it's known to be in violation of a
number of errata from third parties. The "legacy mode" hack is actually
only need on certain systems, which have e.g. a PCIe host bridge with
integrated IO-APIC that snoops the APIC to determine mask status.

I'm going to add a blacklist and quirks instead, as doing
level->edge->level otherwise causes us to start losing interrupts on
other systems. I will supply more information later - this is a somewhat
involved problem that we (Red Hat) have been looking at for a while.

Jon.