Next Previous Contents

11. Serial Tips And Miscellany

Here are some serial tips you might find helpful...

11.1 Line Drivers

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.

11.2 Known Defective Hardware

Avoiding IO Address Conflicts with Certain Video Boards

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.

Problem with AMD Elan SC400 CPU (PC-on-a-chip)

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?

11.3 What Are Lock Files ?

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.


Next Previous Contents