It is _not_ a legitimate answer.
We can have shared PCI interrupts through the traditional APIC controller
too. They don't have a counter, and they never will.
Thus, a counter is _wrong_, because it makes the SMP version work very
very differently from the UP version (btw, I also think that we should
decouple "SMP" and "IO-APIC" as they are completely orthogonal issues, but
we should definitely wait until the IO-APIC code is stable on SMP for
that).
> it's easy. Theoretically the current code should never go beyond 'events
> == 1', just put some logging code there. If you can somehow achieve that
> it never goes beyond 1 then bingo, no need for counters. I have tried hard
> and i failed.
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.
In short, if the ne2000 driver has problems with spurious interrupts, or
lost interrupts during interrupt processing, then it is a problem with the
ne2000. Becuase that can happen even without an IO-APIC.
Any driver that believes that there is a 1:1 relationship between "events"
and "interrupts" is just bound to fail. My latest flag-code guarantees
that if you saw an interrupt (or a hundred) during the processing of an
older interrupt, then the interrupt routine will be called again (for as
long as we get nested interrupts). But it will not queue up the
interrupts, so any correct driver will do something like
irq_handler()
{
while (packets in in-queue) {
handle packet;
}
}
and a driver that does something like this
irq_handler()
{
if (packet in in-queue) {
handle packet;
}
}
is _broken_.
I'd like to (again) point out that this is nothing new. This has _always_
been true, because this is how the interrupts under Linux have worked
since Day 1. It may be that on your particular machine, using the IO-APIC
shows up some timing issue that you hadn't seen before, but that
timing-issue has existed before, and your machine just didn't happen to
see it. I bet other machines have seen it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu