Messages in this thread | | | Date | Wed, 27 Oct 1999 10:47:02 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: serial.c (half duplex support) |
| |
Date: Wed, 27 Oct 1999 15:18:19 +0200 (MEST) From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
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/
| |