One of the things I didn't know back then is that Linux allways lets
the tx buffer drain completely, and then refills it to the top. This
means that if the TX buffer empty interrupt isn't serviced within one
character time (The transmitter shift register is shifting out one last
character when the FIFO is empty...), there is a gap. Those gaps may
be interpreted as an "end of packet" indication. That is unacceptable.
Linux often turns off interrrupts for "too long". Especially when
there are IDE disks near the machine....
I don't think this is really an issue on modern systems; nearly all IDE
controllers support DMA now, so the interrupt masking is much less of an
issue.
And on older machines, due to deficiencies of most UART's (the Oxford
Semiconductor is a recent entry, and not likely to be found on older
systems), it's not practical to do transmit FIFO management any other
way. The 16550A doesn't have a transmit FIFO trigger level at all, and
the other UART's which do, don't have a way of querying the level of the
transmit FIFO once you're in the interrupt handler.
If we have times when the interrupts are turned off for four character
times, we've got other problems....
- Ted
P.S. The other issue that concerns me is that touching the interrupt
driver is delicate business; there are so many different UART's out
there, all of them slightly different, there's significant risk when
trying to use an alternative mechanism. For example right now we don't
touch the ISR register at all. If we start relying on the ISR, then we
have to start worrying about whether all the UART manufactuers
implemented the ISR register the same way. I've been screwed enough by
different manufactuers (especially StarTech) making incompatible changes
in their UART's that I've gotten extremely paranoid about these sorts of
things.
So if this really is a problem were we're really seeing interrupt gaps,
then let's address it. But I'm not really sure this is a problem.
Let's not make trouble for ourselves --- we have enough other things to
keep ourselves busy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/