Here are some serial tips you might find helpful...
For a text terminal, the EIA-232 speeds are fast enough but the usable cable length is often too short. Balanced technology could fix this. The common method of obtaining balanced communication with a text terminal is to install 2@ line drivers in the serial line to convert unbalanced to balanced (and conversely). They are a specialty item and are expensive if purchased new.
The IO address of the IBM 8514 video board (and others) is
allegedly 0x?2e8 where ? is 2, 4, 8, or 9. This may conflict (but
shouldn't it the serial port is well designed) with the IO address of
ttyS3 at 0x02e8 if the serial port ignores the leading 0 hex
digit when it decodes the address (many do). That is bad news if you
try to use ttyS3 at this IO address. Another story is that Linux
will not detect your internal modem on ttyS3 but that you can use
setserial to put ttyS3 at this address and the modem
will work fine.
This has a race condition between an interrupt and a status register of the UART. An interrupt is issued when the UART transmitter finishes the transmission of a byte and the UART transmit buffer becomes empty (waiting for the next byte). But a status register of the UART doesn't get updated fast enough to reflect this. As a result, the interrupt service routine rapidly checks and determines (erroneously) that nothing has happened. Thus no byte is sent to the port to be transmitted and the UART transmitter waits in vain for a byte that never arrives. If the interrupt service routine had waited just a bit longer before checking the status register, then it would have been updated to reflect the true state and all would be OK.
There is a proposal to fix this by patching the serial driver. But Should linux be patched to accommodate defective hardware, especially if this patch may impair performance of good hardware?
A lock file is simply a file saying that a particular device is in use.
They are kept in /var/lock. Formerly they were in
/usr/spool/uucp. Linux lock files are named
LCK..name, where name is either a device name, or a
UUCP site name. Certain processes create these locks so that they can
have exclusive access to devices. For instance if you dial out on
your modem, a lock will appear telling other processes that someone is
using the modem already. Locks mainly contain the PID of the process
that has locked the device. Most programs look at the lock, and try
to determine if that lock is still valid by checking the process table
for the process that has locked the device. If the lock is found to
be valid, the program (should) exit. If not, some programs remove the
stale lock, and use the device, creating their own lock in the
process. Other programs just exit and tell you that the device is in
use.
Having the same physical serial port known by two different device names (such as ttyS0 and cua0) could cause problems. The lock checking software is aware of ttyS vs. cua but it will make things simpler in this regard by the planned elimination of cua. In other cases, assigning an alternate name to the same device is asking for trouble.