159 lines
8.1 KiB
HTML
159 lines
8.1 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE> Serial HOWTO: Serial Tips And Miscellany</TITLE>
|
|
<LINK HREF="Serial-HOWTO-16.html" REL=next>
|
|
<LINK HREF="Serial-HOWTO-14.html" REL=previous>
|
|
<LINK HREF="Serial-HOWTO.html#toc15" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Serial-HOWTO-16.html">Next</A>
|
|
<A HREF="Serial-HOWTO-14.html">Previous</A>
|
|
<A HREF="Serial-HOWTO.html#toc15">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s15">15.</A> <A HREF="Serial-HOWTO.html#toc15">Serial Tips And Miscellany</A></H2>
|
|
|
|
<H2><A NAME="ser_module"></A> <A NAME="ss15.1">15.1</A> <A HREF="Serial-HOWTO.html#toc15.1">Serial Modules </A>
|
|
</H2>
|
|
|
|
<P> Often the serial driver is provided as a module(s) such as
|
|
generic_serial.ko. Drivers for USB serial ports and multiport cards
|
|
are often provided as modules. Linux should automatically load any
|
|
needed module, so in most cases you have nothing to do. </P>
|
|
<P>But sometimes you need to configure Linux to load certain modules or
|
|
gives parameters to the module or to the kernel.</P>
|
|
<P>Such parameters may be supplied to certain modules on the command line
|
|
for the kernel or in /etc/modules, /etc/modules.conf or
|
|
/etc/modprobe.conf. Since kernel 2.2 you don't edit the modprobe.conf
|
|
file but use the program update-modules to change it. The info that
|
|
is used to update modules.conf is put in /etc/modutils/. </P>
|
|
<P>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.</P>
|
|
<P>Serial modules are found in subdirectories of
|
|
<CODE>/lib/modules/.../kernel/drivers/</CODE>. For multiport cards, look
|
|
in the <CODE>serial</CODE> subdirectory and/or <CODE>char</CODE>. For USB serial,
|
|
look in the <CODE>usb/serial</CODE> subdirectory. The module,
|
|
parport_serial is for PCI cards that contain both serial and parallel
|
|
ports. </P>
|
|
<P>As a last resort, 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.</P>
|
|
|
|
<H2><A NAME="kernel_conf"></A> <A NAME="ss15.2">15.2</A> <A HREF="Serial-HOWTO.html#toc15.2">Kernel Configuration </A>
|
|
</H2>
|
|
|
|
<H2><A NAME="nr_ports"></A> <A NAME="ss15.3">15.3</A> <A HREF="Serial-HOWTO.html#toc15.3">Number of Serial Ports Supported </A>
|
|
</H2>
|
|
|
|
<P>If you have more than 4 (or possibly 2) serial ports, then you must
|
|
insure that the kernel knows this. It can be done by configuring the
|
|
kernel when compiling or by a parameter given to the kernel when it
|
|
starts (boot-prompt or kernel command line).</P>
|
|
<P>The kernel configuration parameters:
|
|
CONFIG_SERIAL_8250_RUNTIME_UARTS=4 and CONFIG_SERIAL_8250_NR_UARTS=4
|
|
set the maximum number of ordinary serial ports (UARTs) equal to 4.
|
|
If you have more than 4 ordinary serial ports, then you need to change
|
|
the 4 to whatever. But you may override this via the kernel command
|
|
line for example: nr_uarts=16 (if serial support built into the
|
|
kernel) or 8250.nr_uarts=16 (if serial support is via a module). The
|
|
boot loader such as lilo or grub can be told to do this.</P>
|
|
|
|
<H2><A NAME="ss15.4">15.4</A> <A HREF="Serial-HOWTO.html#toc15.4">Serial Console (console on the serial port)</A>
|
|
</H2>
|
|
|
|
<P> See the kernel documentation in: Documentation/serial-console.txt.
|
|
Kernel 2.4+ has better documentation. See also "Serial Console" in
|
|
Text-Terminal-HOWTO.</P>
|
|
|
|
<H2><A NAME="ss15.5">15.5</A> <A HREF="Serial-HOWTO.html#toc15.5">Line Drivers</A>
|
|
</H2>
|
|
|
|
<P> For a text terminal, the RS-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.</P>
|
|
|
|
<H2><A NAME="ss15.6">15.6</A> <A HREF="Serial-HOWTO.html#toc15.6">Stopping the Data Flow when Printing, etc.</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss15.7">15.7</A> <A HREF="Serial-HOWTO.html#toc15.7">Known IO Address Conflicts</A>
|
|
</H2>
|
|
|
|
<H3><A NAME="video_8514"></A> Avoiding IO Address Conflicts with Certain Video Boards </H3>
|
|
|
|
<P> 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
|
|
<CODE>ttyS3</CODE> 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 <CODE>ttyS3</CODE> at this IO address. Another story is that Linux
|
|
will not detect your internal modem on <CODE>ttyS3</CODE> but that you can use
|
|
<CODE>setserial</CODE> to put <CODE>ttyS3</CODE> at this address and the modem
|
|
will work fine.</P>
|
|
<H3>IO address conflict with ide2 hard drive</H3>
|
|
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss15.8">15.8</A> <A HREF="Serial-HOWTO.html#toc15.8">Known Defective Hardware</A>
|
|
</H2>
|
|
|
|
<H3>Problem with AMD Elan SC400 CPU (PC-on-a-chip)</H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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?</P>
|
|
|
|
<HR>
|
|
<A HREF="Serial-HOWTO-16.html">Next</A>
|
|
<A HREF="Serial-HOWTO-14.html">Previous</A>
|
|
<A HREF="Serial-HOWTO.html#toc15">Contents</A>
|
|
</BODY>
|
|
</HTML>
|