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.
On some multiport serial cards, there is an I/O port you can query to
determine whether there are any outstanding interrupts on all of the
card's ports. Unfortunately, there's no standardization where this port
might be, and whether 0 or 1 means no interrupt pending. Thus, the user
needs to carfully configure the serial driver using setserial in order
to take advantage of the rs_multiport feature, but for those users who
can, this significantly speeds up the serial interrupt processing and
reduces the race condition that leads towards hung serial ports.
The bottom line is that if you going to support shared interrupts for
the ISA bus in the general case, there are many, many, many little
subtleties that you will need to get right.
- Ted