Next
Previous
Contents
Often the serial driver is provided as a module. Parameters may
be supplied to certain modules in /etc/modules.conf or
/etc/modprobe.conf. Since kernel 2.2 you don't edit this file but use
the program update-modules to change it. The info that is used to
update modules.conf is put in /etc/modutils/.
The Debian/GNU Linux has a file named /etc/modutils/setserial which
runs the serial script in /etc/init.d/ every time the serial module is
loaded or unloaded. When the serial module is unloaded this script
will save the state of the module in /var/run/setserial.conf. Then if
the module loads again this saved state is restored. When the serial
module first loads at boot-time, there's nothing in
/var/run/setserial.conf so the state is obtained from
/etc/serial.conf. So there are two files that save the state. Other
distributions may do something similar.
The module, parport_serial is for PCI cards that contain both serial
and parallel ports.
One may modify the serial driver by editing the source code. Much of
the serial driver is found in the file serial.c. For info
regarding writing of programs for the serial port see
Serial-Programming-HOWTO. It was revised in 1999 by Vern Hoxie but
that revision is not at LDP.
See the kernel documentation in: Documentation/serial-console.txt.
Kernel 2.4+ has better documentation. See also "Serial Console" in
Text-Terminal-HOWTO.
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.
Normally flow control and/or application programs stop the flow of
bytes when its needed. But sometimes they don't. The problem is that
output to the serial port first passes thru the large serial buffer
in the PC's main memory. So if you want to abort printing, whatever is
in this buffer should be removed. When you tell an application program
to stop printing, it may not empty this buffer so printing continues
until it's empty. In addition, your printer has it's own buffer which
needs to be cleared. So telling the PC to stop printing may not work
due to these two buffers that continue to supply bytes for the printer.
It's a problem with printer software not knowing about the serial port
and that modem control lines need to be dropped to stop the printer.
One way to insure that printing stops is to just turn off the printer.
With newer serial drivers, this works OK. The buffers are cleared and
printing doesn't resume. With older serial drivers, the PC's serial
buffer didn't clear and it would sometimes continue to print when the
printer was turned back on. To avoid this, you must wait a time
specified by setserial's closing_wait before turning the printer back
on again. You may also need to remove the print job from the print
queue so it won't try to resume.
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 if 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.
IO address conflict with ide2 hard drive
The address of ttyS2 is 3e8-3ef while hard drive ide2 uses 3ee
which is in this range. So when booting Linux you may see a report
of this conflict. Most people don't use ide2 (the 3rd hard drive
cable) and may ignore this conflict message. You may have 2 hard
drives on ide0 and two more on ide1 so most people don't need ide2.
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?
Next
Previous
Contents
|