On Thu, 29 Jun 1995, Theodore Ts'o wrote:
>
> One of the reasons for the large amount of ugliness and hair in the
> serial driver interrupt handler is because if you have two serial ports
> sharing the same interrupt, the following situation can happen:
>
> 1) Device A signals an interrupt
> 2) Kernel dispatches to the serial interrupt routine
> 3) Device B signals an interrupt
> 4) Kernel services device A
> 5) Kernel starts servicing device B
> 6) Device A signals an interrupt
> 7) The Kernel, having finished servicing devices A and B, returns
> without servicing device A second time.
> 8) Device A locks up.
>
> I have had people argue that the programmable interrupt controller is
> supposed to work, this scenario isn't supposed to happen. All I can say
> is, on too many machines, it does.
>
> The workaround is that serial driver has to poll all of the devices
> sharing an interrupt, waiting for a time when all of the devices return
> "no servicing is necessary", before it returns and acknolweges the
> interrupt. There is a race condition that is inherently in trying to
> sequentially poll all of the devices, so we need to make this happen as
> quickly as possible.
>
> - Ted
Is it possible to first acknowledge the interrupt and then scan for
devices to service on this interrupt. This way you may get an interrupt
that has already been serviced, but you will never loose any service
requests.
Is this exactly what the crippled PC hardware prevents us from doing?
/Kurt
-- Kurt Wachmann, M.Sc.EE - kw@netman.dk Distribution of this article via Microsoft Network is prohibited.