Re: [patch] IRQ threads

[Alan Cox]

On Iau, 2004-07-29 at 21:21, Scott Wood wrote:
> The intent is to make enable_irq() robust against calls while the
> thread is still running/pending (such as if the thread has lower
> priority than the task that calls enable_irq()).  This implies that
> the preceding disable was of the _nosync() variety.
> 
> I believe we saw drivers/net/8390.c doing this, and it was causing an

8390 does a disable_irq_nosync having previously cleared the IRQ on the
controller. This is neccessary because IRQ arrival on PC hardware is
asynchronous to all other busses and can take incredibly long times on
SMP hardware prior to PIV.  Thus it happens now and then that the
controller emits an IRQ, we clear the source, the clear is done and
later the IRQ arrives that has already been cleared down on the original
IRQ source. Most drivers just use spinlocks but the 8390 is
so slow that is has to pull other stunts or even things like serial
ports and the 1Khz clock slide.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/