> The point is not whether you can see a count > 1.
>
> I _believe_ you when you say that you can see a count larger than one. I
> just do not find that to be an argument at all, for the reasons outlined
> above. We'd better not queue up interrupts to _any_ depth other than a
> single one, because that is not what anything else does.
i was not aware of the comulative nature of the 'flag' approach, my
mistake. Your approach is simple and robust. I think even the NE2000
driver will work, i attribute the reported NE2K instabilities to the fact
that the self-IPI part was always much less obvious than it seems.
i think Rogier Wolf's comment is still valid (it's a completely separate
issue). We first ACK the _local_ APIC, which in turn generates 'ack' type
APIC messages towards the IO-APIC, and the IO-APIC 'frees' the line. If we
have PCI level triggered interrupts, then we might see yet another, not
justified interrupt, in case the driver is too slow (for whatever reason)
to ACK the IRQ on the hardware card itself, so it releases the line.
i estimate there is an about 10-20 usecs 'window' after ACK-ing the local
APIC, if we dont handle the card in this period of time, we'll see a
spurious interrupt. This interrupt is not fatal (if the driver keeps
interrupts disabled until it's own ACK), but unnecessary nevertheless.
what is a bit confusing is that this should be a problem on non-SMP
systems too. Without checking docs, i think the 8259A also 'accumulates'
up to one interrupt even if the line is disabled. Only level-triggered
interrupt sources are affected.
currently we do:
do_IRQ()
...
ack_local_APIC()
...
...
outb(DRIVERS_PORT,1) /* ack the IRQ in the card */
shouldnt we do:
do_IRQ()
...
...
outb(DRIVERS_PORT,1) /* ack the IRQ in the card */
ack_local_APIC()
the chance for a delay until we do the card-specific ack increases with
the use of spinlocks. (like in the SCSI code) But if we use this second
approach we get other problems: an unACKed local APIC accepts _no_
interrupts at all, not even NMI's.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu