On Saturday 11 December 2004 01:57, you wrote:
> On Sad, 2004-12-11 at 01:23, Linus Torvalds wrote:
> > > Until the 10,000th event it actually seems to work rather happily
> > > without that change.
> > 
> > I suspect you never tried the level-triggered case.
> 
> Level triggered has never been supported. Putting a single disable_irq
> in doesn't change the fact it doesn't work because the IRQ is never
> re-enabled.

The real very first reason for disable_irq introduction has been
infinite list of unbalanced enable_irq calls reported in the syslog,
caused by enable_irq(irqnumber) call from get_and_reset_irq().
It has been there for ages.
Not nice behavior. You see 100000 of such messages and then
processing stops on IRQ_NONE catch. I am voting for benefit of
our _very_ small VM86 IRQ emulation users community, that actual
state is many times better, than previous state. It is usable now.
I believe, that even level triggered interrupts should work
now without problems. We will give this feature real load testing.
We use it for educational DC motor control. 10kHz of IRQs.
We know, that even 2.6.x with preempt cannot handle that
without IRQ misses. But it is nice test to see on a osciloscope,
how userspace task reacts on IRQ events. And I think,
that 2.6.x kernel can evolve to one millisecond guaranteed response
time one day. It would be great. We have experience with real
drivers and writting code for RT-Linux as well.
I do not believe, that 2.6 kernels could get under 300 us
in reasonable future, so somethink like RT-Linux or dedicated
MCU would be still required for more demanding tasks.
But one millisecond could be enough for many complex control tasks.

Thanks for care

                Pavel

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