> I've made some other changes in my tree already, I always found the
> repeating and counting to be of dubious value - if we have nested
> interrupts there is no point in trying to count them up. 2.1.98 makes one
> counter be a simple flag, and I think the other counters should be simple
> flags too.
Actually, I was already wondering why one should send the same irq
n-times to the same handler ...
> Would some io-apic people try out this patch to irq.c (patch against
> 2.1.98)? It simplifies the irq handling quite a bit, I'd like to hear
> whether it is stable for you..
Will check tomorrow, just too tired. For ftape it will most probably
work fine. Only problem could be for dunno what driver/hardware
combination that disable_irq() really discards interrupts. Which can
of course be avoided by using a spin-lock scheme rather than trying to
disable interrupts. Only that disabling an interrupt hits performance
less badly than a spin-lock with the lock held for a long time.
Claus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu