LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2003-11-25 23:38:40 +00:00
parent cddb0382c9
commit 6e82f3e19c
3 changed files with 1135 additions and 886 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

954
LDP/howto/linuxdoc/Modem-HOWTO.sgml
View File

File diff suppressed because it is too large Load Diff

518
LDP/howto/linuxdoc/Serial-HOWTO.sgml
View File

@ -4,12 +4,13 @@
<author>David S.Lawyer
<tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
original by Greg Hankins
<date> v2.20 October 2003
<date> v2.21 November 2003
<!-- Change log:
v2.20 MAKEDEV is often only in /sbin and not in /dev.
v2.19 linux-serial email now at kernel.org, new section: Servers,
pinout diagram
v2.21 Nov. 2003: Kernel compile USB options for serial ports, revised setserial
v2.20 Oct. 2003: MAKEDEV is often only in /sbin and not in /dev.
v2.19 Sept. 2003: linux-serial email now at kernel.org, new
section: Servers, pinout diagram
v2.18 May 2003: EIA-485 features not supported by Linux, Flow control
"typos" fixed
v2.17 Feb. 2003 url signum->cendio, Mac port names, clarity when
@ -140,7 +141,7 @@ sites see: <url url="http://www.tldp.org/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
url="http://www.tldp.org/HOWTO/Serial-HOWTO.html"> and compare
it to this version: v2.20 October 2003 .
it to this version: v2.21 November 2003 .
<sect1>New in Recent Versions
<p> For a full revision history going back to the time I started
@ -149,6 +150,7 @@ maintaining this HOWTO, see the source file (in linuxdoc format) at
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Serial-HOWTO.sgml.gz">.
<itemize>
<item>v2.21 Nov. 2003 Kernel compile USB options for serial ports, revised setserial
<item>v2.20 Oct. 2003: MAKEDEV is often only in /sbin and not in /dev.
<item>v2.19 September 2003: linux-serial email now at kernel.org, new
section: Servers, pinout diagram
@ -1347,14 +1349,17 @@ url="http://www.perle.com/downloads/multi_port.html"> <newline>
name="ftp://ftp.stallion.com/drivers/ata5/Linux"></tt> and
included in linux kernel since 1.3.27
moved; it's now at
<item>System Base
website: <url url="http://www.sysbas.com/">
</itemize>
<p>
A review of Comtrol, Cyclades, Digi, and Stallion products was printed
in the June 1995 issue of the <EM/Linux Journal/. The article is
available at <tt><htmlurl url="http://www.ssc.com/lj/issue14"
<p>A review of Comtrol, Cyclades, Digi, and Stallion products was
printed in the June 1995 issue of the <EM/Linux Journal/. The article
is available at <tt><url url="
http://www.linuxjournal.com/article.php?sid=1097">
name="http://www.ssc.com/lj/issue14"></tt>.
<sect1> Unsupported Multiport Boards
@ -2329,66 +2334,118 @@ Nov. 2000: auto_irq may work on the 2nd try
Dec. 2000: saving state of serial module
June 2001 OK to use setserial with Laptops
Nov. 2002 Debian's /var/lib/serial.conf
Nov. 2003 Major revision, since today, plug-and-play dominates
/var/lib/setserial/autoserial.conf
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
<sect2> Introduction
<sect2>Important information
<p>
If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
read <ref id="laptops_" name="Laptops: PCMCIA">. <tt/setserial/ is a
program which allows you to tell the device driver software the I/O
address of the serial port, which interrupt (IRQ) is set in the port's
hardware, what type of UART you have, etc. Since there's a good
chance that the serial ports will be automatically detected and set,
many people never need to use <tt/setserial/. In any case setserial
will not work without either serial support built into the kernel or
loaded as a module. The module may get loaded automatically if you
(or a script) tries to use setserial.
read <ref id="laptops_" name="Laptops: PCMCIA">.
Setserial can also show how the driver is currently set. In addition,
it can be made to probe the hardware I0 port addresses to try to
determine the UART type and IRQ, but this has severe limitations. See
<ref id="probing_ss" name="Probing">. Note that it can't set the IRQ
or the port address in the hardware of PnP serial ports (but the
plug-and-play features of the serial driver may do this). It can't
read the PnP data stored in configuration registers in the hardware.
The term PnP means Plug-and-Play. All serial ports on the PCI bus are
PnP and many on the ISA bus are also PnP. Linux software with the
term "pnp" in it is usually only for the ISA bus. The PCI bus is
inherently PnP so sofware for dealing with PnP on the PCI bus
usually contains the term "pci" but not "pnp".
If you only have one or two built-in serial ports, they will usually
get set up correctly without using setserial. Otherwise, if you add
more serial ports (such as a modem card) you may need to deal with
setserial. Besides the man page for <tt/setserial/, check out info in
<sect2> Introduction
<p><tt/setserial/ is a program which allows you (or a shell script) to
talk to the serial device driver software. You may use it to tell the
device driver how the hardware is phsically set (I/O addrees, IRQ,
etc.). But normally, the device drivers finds out this infomation
itself so that you don't need to use <tt/setserial/. But if the device
driver can't find a serial port (or perhaps gets the IRQ wrong) and
you can find out this infomation while the driver can't, then
<tt/setserial/ is essential. How to find serial ports is covered
elsewhere, and in a minority of cases, <tt/setserial/ will be useful
to help find them.
<tt/setserial/ permits you (or a script) to configure the serial port
by telling the device driver the I/O address of the serial port, which
interrupt (IRQ) is set in the port's hardware, what type of UART you
have, etc. The name <tt/setserial/ is somewhat of a misnomer since it
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
them in the driver software. And the driver naively believes that
what <tt/setserial/ tells it has already been set in the hardware.
Since the device driver is considered to be part of the kernel, the
word "kernel" is often used in other documentation with no mention
made of any "serial driver".
Some distributions (and versions) set things up so that <tt/setserial/ is
run at boot-time by an initialization shell script (usually in the
/etc directory tree). In other cases, you have to take some action to
run <tt/setserial/ at boot-time. <tt/setserial/ will not work without
either serial support built into the kernel or loaded as a module.
The module may get loaded automatically if you (or a script) attempt
to use setserial.
In addition to using <tt/setserial/ to configure, <tt/setserial/ can
show you how the driver is currently configured (set). Hopefully, the
hardware is set the same. In addition, it can be made to probe the
hardware I0 port addresses to try to determine the UART type and IRQ,
but this has severe limitations. See <ref id="probing_ss"
name="Probing">. Note that it can't set the IRQ or the port address
in the hardware of PnP serial ports (but the plug-and-play features of
the serial driver may do this). It also can't directly read the PnP
data stored in configuration registers in the hardware. But since the
device driver can read these registers, <tt/setserial/ could be
telling you what's in them, or it could be telling you what
<tt/setserial/ had previously (and perhaps erroneously) told the
driver. There's no way to know for sure without doing some other
checks.
The serial driver (for Linux 2.4+) looks for a few "standard" legacy
serial ports, for PnP ports on the ISA bus, and for all supported port
hardware on the PCI bus. If it finds these OK then there's no need to
use <tt/setserial/. The driver doesn't probe for legacy IRQs and may
get these wrong.
Besides the man page for <tt/setserial/, check out info in
<tt>/usr/doc/setserial.../</tt> or <tt>/usr/share/doc/setserial</tt>.
It should tell you how setserial is handled in your distribution of
Linux.
Linux. While <tt/setserial/ behaves the same in all distributions,
the scripts for running it, how to configure such scripts (including
automatic configuration), and the names and locations of the script
files, etc., are all distribution-dependent.
<tt/Setserial/ is often run automatically at boot-time by a start-up
shell-script for the purpose of assigning IRQs, etc. to the driver.
Setserial will only work if the serial module is loaded (or if the
equivalent was compiled into your kernel). If the serial module gets
unloaded later on, the changes previously made by <tt/setserial/ will
be forgotten by the kernel. But recent (2000) distributions may
contain scripts that save and restore this. If not, then
<tt/setserial/ must be run again to reestablish them. In addition to
running via a start-up script, something akin to <tt/setserial/ also
runs earlier when the serial module is loaded (or the like). Thus
when you watch the start-up messages on the screen it may look like it
ran twice, and in fact it has.
<sect2>Serial module unload
<p>If a serial module gets unloaded, the changes previously made by
<tt/setserial/ will be forgotten by the driver. But while the driver
forgets it, a script provided by the distribution may save it in a
file somewhere so that it can the restored if the module is reloaded.
Setserial can set the time that the port will keep operating after
it's closed (in order to output any characters still in its buffer in
main RAM). This is needed at slow baud rates of 1200 or lower. It's
also needed at higher speeds if there are a lot of "flow control"
waits. See "closing_wait" in the setserial man page.
<sect2>Slow baud rates of 1200 or less
<p>There once was a problem with slow serial printers (especially the
old ones of the 1980s). The printing program would close the serial
port at the "end" of printing well before all the characters from the
large serial buffer (in main memory) were sent to the printer. The
result was a truncated print job that didn't print the last paragraph
or last page, etc.
But the newer lprng print program (and possibly other printing
programs) keeps the port open until printing is finished so "problem
solved", even if you're using an antique printer. Setserial can
modify the time that the port will keep operating after it's closed
(in order to output any characters still in its buffer in main RAM).
This is done by the "closing_wait" option per the <tt/setserial/ man
page. For "bad" software that closes the port too soon, it might also
be needed at speeds above 1200 if there are a lot of "flow control"
waits.
Setserial does not set either IRQ's nor I/O addresses in the serial
port hardware itself. That is done either by jumpers or by
plug-and-play. You must tell setserial the identical values that have
been set in the hardware. Do not just invent some values that you
think would be nice to use and then tell them to setserial. However,
if you know the I/O address but don't know the IRQ you may command
setserial to attempt to determine the IRQ.
<sect2>Giving the <tt/setserial/ command
<p>Remember, that <tt/setserial/ can't set any I/O addresses or IRQs
in the hardware. That's done either by plug-and-play software (run by
the driver) or by jumpers for legacy serial ports. Even if you give
an I/O address or IRQ to the driver via <tt/setserial/ it will not set
such values and assumes that they have already been set. If you give
it wrong values, the serial port will not work right (if at all).
For legacy ports, if you know the I/O address but don't know the IRQ
you may command setserial to attempt to determine the IRQ.
You can see a list of possible commands by just typing <tt/setserial/
with no arguments. This fails to show you the one-letter options such
@ -2397,9 +2454,9 @@ Note that setserial calls an IO address a "port". If you type:
<tscreen><verb>
setserial -g /dev/ttyS*
</verb></tscreen>
you'll see some info about how that device driver is configured for
you'll see some info about how the device driver is configured for
your ports. Note that where it says <tt>"UART: unknown"</tt> it
probably means that no uart exists. In other words you probably have
probably means that no uart exists. In other words, you probably have
no such serial port and the other info shown about the port is
meaningless and should be ignored. If you really do have such a
serial port, setserial doesn't recognize it and that needs to be
@ -2408,40 +2465,61 @@ fixed.
If you add -a to the option -g you will see more info although few
people need to deal with (or understand) this additional info since
the default settings you see usually work fine. In normal cases the
hardware is set up the same way as "setserial" reports, but if you are
having problems there is a good chance that "setserial" has it wrong.
hardware is set up the same way as "setserial" reports. But if you are
having problems there is a good chance that <tt/setserial/ has it wrong.
In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. They will also be officially
bogus values you've supplied to the driver. They will also be officially
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command (Debian). Of course the serial
port driver will not work correctly (if at all) if you attempt to use
such a port. Thus when giving parameters to "setserial" anything
goes. Well almost. If you assign one port a base address that is
such a port. Thus, when giving parameters to <tt/setserial/, "anything
goes". Well almost. If you assign one port a base address that is
already assigned (such as 3e8) it may not accept it. But if you use
3e9 it will accept it. Unfortunately 3e9 is already assigned since it
3e9 it will accept it. Unfortunately 3e9 is actually assigned since it
is within the range starting at base address 3e8. Thus the moral of
the story is to make sure your data is correct before assigning
resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
configuration) when the PC is started up again. In newer versions,
what you change by setserial may get automatically saved to a
configuration file. In older versions, the configuration file only
changes if you edit it manually so the configuration always remains
the same from boot to boot. See <ref id="ss_conf_script"
name="Configuration Scripts/Files">
<sect2>Configuration file
<p>While assignments made by setserial are lost when the PC is powered
off, a configuration file usually restores them when the PC is started
up again. In newer versions, what you change by setserial might get
automatically saved to a configuration file. When <tt/setserial/ runs
it uses the info from the the configuration file. In Debian there are
4 options for use of this configuration file:
<enum>
<item>Don't use this file at all. At each boot, the serial driver
alone detects the ports and setserial doesn't ever run. ("kernel" option)
<item>Save what <tt/setserial/ reports when the system is first
shutdown and put it in the configuration file. After that, don't ever
make any changes to the configuration file, even if someone has made
changes by running the <tt/setserial/ command on the command line and
then shuts down the system. ("autosave-once" option)
<item>At every shutdown, save whatever <tt/setserial/ detects to the
configuration file. ("autosave" option)
<item>Manually edit the configuration file to set the configuration.
Don't ever do any automatic saves to it. ("manual" option)
</enum>
In old versions (perhaps before 2000), there wasn't any configuration
file and the configuration was manually set (hard coded) inside the
shell script that ran <tt/setserial/. See <ref id="old_sets_script"
name="Edit a script (prior to version 2.15)">.
<sect2> Probing <label id="probing_ss">
<p>Prior to probing with "setserial", one may run the "scanport"
(Debian) command to check all possible ports in one scan. It makes
crude guesses as to what is on some ports but doesn't determine the
IRQ. But it's a fast first start. It may hang your PC but so far
it's worked fine for me. Note that non-Debian distributions don't
seem to supply "scanport". Is there an another scan program?
<p>You probe for a port only when you suspect that it has been enabled
(by PnP methods ,the BIOS, jumbers, etc.), otherwise setserial probing
will never find it since its address doesn't exist. Probling is where
the software looks for a port at specified I/O addresses. Prior to
probing with "setserial", one may run the "scanport" (Debian) command
to check all possible ports in one scan. It makes crude guesses as to
what is on some ports but doesn't determine the IRQ. It's a fast
first start. It may hang your PC but so far it's worked fine for me.
Note that non-Debian distributions don't seem to supply "scanport".
Is there another scan program?
With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
@ -2450,181 +2528,173 @@ address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
is at a different address, then it will probe at that address, etc.
See <ref id="probing_ss" name="Probing">
The purpose of this is to see if there is a uart there, and if so,
what its IRQ is. Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using <tt>pnpdump
The purpose of such probing is to see if there is a uart there, and if
so, what its IRQ is. Use <tt/setserial/ mainly as a last resort as
there are faster ways to attempt it such as wvdialconf to detect
modems, looking at very early boot-time messages, or using <tt>pnpdump
--dumpregs</tt>. To try to detect the physical hardware use for
example :<newline>
<tt>setserial /dev/ttyS2 -v autoconfig</tt><newline>
If the resulting message shows a uart type such as 16550A, then you're
OK. If instead it shows "<tt/unknown/" for the uart type, then there
is supposedly no serial port at all at that I/O address. Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.
example :<newline> <tt>setserial /dev/ttyS2 -v
autoconfig</tt><newline> If the resulting message shows a uart type
such as 16550A, then you're OK. If instead it shows "<tt/unknown/"
for the uart type, then there is supposedly no serial port at all at
that I/O address. Some cheap serial ports don't identify themselves
correctly so if you see "<tt/unknown/" you still might have a serial
port there.
Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically saved and put into the
configuration file <tt>/etc/serial.conf</tt> or
<tt>/var/lib/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
last probe test could be automatically saved and put into a
configuration file such as <tt>/etc/serial.conf</tt> or
<tt>/var/lib/setserial/autoserial.conf</tt>. This will be used next
time you start Linux.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
happens anyway. Probing detects one serial port when actually there
are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
<tt/setserial/ to give the IRQ a fictitious value.
the hardware. Of course this is not normally permitted for the ISA
bus but it sometimes happens anyway. Probing detects one serial port
when actually there are two. However if they have different IRQs,
then the probe for IRQs may show IRQ = 0. For me, it only did this if
I first used <tt/setserial/ to give the IRQ a fictitious value.
<sect2>Boot-time Configuration <label id="sets_boot_time">
<p>While <tt/setserial/ may run via an initialization script,
something akin to <tt/setserial/ also runs earlier when the serial
module is loaded (or when the kernel starts the built-in serial driver
if it was compiled into the kernel). Thus when you watch the start-up
messages on the screen it may look like it ran twice, and in fact it
has.
<sect2> Boot-time Configuration <label id="sets_boot_time">
<p> When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
auto-detected and the driver is set to use only IRQs 4 and 3
(regardless of what IRQs are actually set in the hardware). You see
this as a boot-time message just like as if <tt/setserial/ had been
run.
But the IRQs shown may be wrong since it doesn't probe for IRQs. The
second report of the same is the result of a script such as
/etc/init.d/setserial. It usually does no probing and thus could be
wrong about how the hardware is actually set. It only shows
configuration data that got saved in a configuration files. The old
method, prior to setserial 2.15, was to manually write such data
directly into the script.
To correct possible errors in IRQs (or for other reasons) there may be
a file somewhere that runs <tt/setserial/ again. Unfortunately, if
this file has some IRQs wrong, the kernel will still have incorrect
info about the IRQs. This file should run early at boot-time before
any process uses the serial port. In fact, your distribution may have
set things up so that the setserial program runs automatically from a
start-up script at boot-time. More info about how to handle this
situation for your particular distribution might be found in file
named "setserial..." or the like located in directory /usr/doc/ or
/usr/share/doc/.
When the kernel loads the serial module (or if the "module equivalent"
is built into the kernel) then all supported PnP ports are detected.
For legacy (non-PnP) ports, only <tt/ttyS{0-3}/ are auto-detected
and the driver is set to use only IRQs 4 and 3 (regardless of what
IRQs are actually set in the hardware). No probing is done for IRQs
but it's possible to do this manually. You see this as a boot-time
message just as if <tt/setserial/ had been run.
For legacy ports, to correct possible errors in IRQs (or for other
reasons) there is likely a script file somewhere that runs
<tt/setserial/ again. Unfortunately, if this file has some IRQs
wrong, the kernel will still have incorrect info about the IRQs. This
file is usually part of the initialization done at boot-time and
whether it runs or not depends on how you (and/or your distribution)
have set up the running to these initialization scripts. It also
depends on the runlevel.
Before modifying a configuration file, you can test out a "proposed"
<tt/setserial/ command by just typing it on the command line. In some
cases the results of this use of <tt/setserial/ will automatically get
saved in /etc/serial.conf when you shutdown. So if it worked OK (and
solved your problem) then there's no need to modify any configuration
file. See <ref id="new_config" name="New configuration method using
/etc/serial.conf">.
<sect2> Configuration Scripts/Files <label id="ss_conf_script">
<p> Your objective is to modify (or create) a script file in the /etc
tree that runs setserial at boot-time. Most distributions provide
such a file (but it may not initially reside in the /etc tree). In
addition, setserial 2.15 and higher often have an /etc/serial.conf
file that is used by the above script so that you don't need to
directly edit the script that runs setserial. In addition just using
setserial on the command line (2.15+) may ultimately alter this
configuration file.
So prior to version 2.15 all you do is edit a script. After 2.15 you
may need to either do one of three things: 1. edit a script. 2. edit
<tt>/etc/serial.conf</tt> or 3. run "setserial" on the command line
which may result in <tt>/etc/serial.conf</tt> automatically being
edited. Which one of these you need to do depends on both your
particular distribution, and how you have set it up.
file. See <ref id="config_file" name="Configuration method using
/etc/serial.conf, etc.">.
<sect2> Edit a script (required prior to version 2.15)
<label id="old_sets_script">
<p> Prior to setserial 2.15 (1999) there was no /etc/serial.conf file
to configure setserial. Thus you need to find the file that runs
"setserial" at boot time and edit it. If it doesn't exist, you need
to create one (or place the commands in a file that runs early at
boot-time). If such a file is currently being used it's likely
somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
<p> This is how it was done prior to <tt/setserial/ 2.15 (1999)
The objective was to modify (or create) a script file in the /etc
tree that runs setserial at boot-time. Most distributions provided
such a file (but it may not have initially resided in the /etc tree).
So prior to version 2.15 (1999) it was simpler. All you did was edit
a script. There was no /etc/serial.conf file (or the like) to
configure setserial. Thus you needed to find the file that runs
"setserial" at boot time and edit it. If it didn't exist, you needed
to create one (or place the commands in a file that ran early at
boot-time). If such a file was currently being used it's likely
was somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
in /usr/doc/setserial/ but you need to move it to the /etc tree before
using it. You might use "locate" to try to find such a file. For
example, you could type: locate "*serial*".
using it.
The script <tt>/etc/rc.d/rc.serial</tt> was commonly used in the past.
The Debian distribution used <tt>/etc/rc.boot/0setserial</tt>.
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's
not a good idea to use this since it may not be run early enough.
It's been reported that other processes may try to open the serial
port before rc.local runs resulting in serial communication failure.
Today it's most likely in /etc/init.d/ but it isn't normally intended
to be edited.
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's may
not have run early enough. It's was reported that other processes may
try to open the serial port before rc.local ran resulting in serial
communication failure. Later on it's most likely was found in
/etc/init.d/ but wasn't normally intended to be edited.
If such a file is supplied, it should contain a number of
If such a file was supplied, it likely contained a number of
commented-out examples. By uncommenting some of these and/or
modifying them, you should be able to set things up correctly. Make
sure that you are using a valid path for <tt/setserial/, and a valid
modifying them, you could set things up correctly. It was important
use a valid path for <tt/setserial/, and a valid
device name. You could do a test by executing this file manually
(just type its name as the super-user) to see if it works right.
Testing like this is a lot faster than doing repeated reboots to get
Testing like this was a lot faster than doing repeated reboots to get
it right.
For versions >= 2.15 (provided your distribution implemented the
change, Redhat didn't) it may be more tricky to do since the file that
runs setserial on startup, /etc/init.d/setserial or the like was not
intended to be edited by the user. See <ref id="new_config"
name="New configuration method using /etc/serial.conf">.
If you want setserial to automatically determine the uart and the IRQ
for ttyS3 you would add something like:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
Do this for every serial port you want to auto configure. Be sure to
give a device name that really does exist on your machine. In some
cases this will not work right due to the hardware. If you know what
the uart and irq actually are, you may want to assign them explicitly
with "setserial". For example:
intended to be edited by the user. See <ref id="config_file"
name="Configuration method using /etc/serial.conf, etc.">.
An example line in such a script was"
<tscreen><verb>
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
</verb></tscreen>
or, if you wanted setserial to automatically determine the uart and the
IRQ for ttyS3 you would have used something like this:
<sect2> New configuration method using /etc/serial.conf
<label id="new_config">
<p> Prior to setserial version 2.15, the way to configure setserial
<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
This was done for every serial port you wanted to auto configure,
using a device name that really does exist on your machine. In some
cases it didn't work right due to the hardware.
<sect2> Configuration method using /etc/serial.conf, etc.
<label id="config_file">
<p> Prior to setserial version 2.15 (1999), the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
See <ref id="old_sets_script" name="Edit a script (after version 2.15:
perhaps not)">. Starting with version 2.15 (1999) of <tt/setserial/
this shell-script is not edited but instead gets its data from a
configuration file: <tt>/etc/serial.conf</tt>. Furthermore you may
not even need to edit serial.conf because using the "setserial"
command on the command line may automatically cause serial.conf to be
edited appropriately.
See <ref id="old_sets_script" name="Edit a script (before version
2.15)">. Today the script and configuration file are two different
files instead of one. This shell-script is not edited but gets its
data from a configuration file such as <tt>/etc/serial.conf</tt>.
This was intended so that you don't need to edit any file in order to
Furthermore you may not even need to edit serial.conf because using
the "setserial" command on the command line may automatically cause
serial.conf to be edited appropriately.
This was done so that you don't need to edit any file in order to
set up (or change) what setserial does each time that Linux is booted.
But there are serious pitfalls because it's not really "setserial"
that edits serial.conf. Confusion is compounded because different
distributions handle this differently. In addition, you may modify it
so that it works differently.
What often happens is this: When you shut down your PC the script
that runs "setserial" at boot-time is run again, but this time it only
that ran "setserial" at boot-time is run again, but this time it only
does what the part for the "stop" case says to do: It uses
"setserial" to find out what the current state of "setserial" is, and
it puts that info into the <tt>serial.conf</tt> file. Thus when you
run "setserial" to change the serial.conf file, it doesn't get changed
immediately but only when and if you shut down normally.
it puts that info into the serial configuration file such as
<tt>serial.conf</tt>. Thus when you run "setserial" to change
the serial.conf file, it doesn't get changed immediately but only when
and if you shut down normally.
Now you can perhaps guess what problems might occur. Suppose you
don't shut down normally (someone turns the power off, etc.) and the
changes don't get saved. Suppose you experiment with "setserial" and
forget to run it a final time to restore the original state (or make a
mistake in restoring the original state). Then your "experimental"
settings are saved.
settings are saved. There's an option to avoid this in Debian known
as "AUTOSAVE-ONCE" which will be discussed later on.
If you manually edit serial.conf, then your editing is destroyed when
you shut down because it gets changed back to the state of setserial
at shutdown. There is a way to disable the changing of serial.conf at
shutdown and that is to remove "###AUTOSAVE###" or the like from first
line of serial.conf. In at least one distribution, the removal of
"###AUTOSAVE###" from the first line is automatically done after the
first time you shutdown just after installation. The serial.conf file
should contain some comments to explain this.
line of serial.conf. In the Debian distribution, the removal of
"###AUTOSAVE###" from the first line was once automatically done after
the first time you shutdown just after installation. To retain this
effect the "AUTOSAVE-ONCE" option was created which only saves the
first time the system is shut down.
The file most commonly used to run setserial at boot-time (in
conformance with the configuration file) is now /etc/init.d/setserial
@ -2633,19 +2703,19 @@ normally be edited. For 2.15, Redhat 6.0 just had a file
/usr/doc/setserial-2.15/rc.serial which you have to move to
/etc/init.d/ if you want setserial to run at boot-time.
To disable a port, use <tt/setserial/ to set it to
"uart none". The format of /etc/serial.conf appears to be just like
that of the parameters placed after "setserial" on the command line
with one line for each port. If you don't use autosave, you may edit
/etc/serial.conf manually.
To disable a port, use <tt/setserial/ to set it to "uart none". This
will not be saved. The format of /etc/serial.conf appears to be just
like that of the parameters placed after "setserial" on the command
line with one line for each port. If you don't use autosave, you may
edit /etc/serial.conf manually.
BUG: As of July 1999 there is a bug/problem since with ###AUTOSAVE###
only the setserial parameters displayed by "setserial -Gg /dev/ttyS*"
get saved but the other parameters don't get saved. Use the -a flag
to "setserial" to see all parameters. This will only affect a small
minority of users since the defaults for the parameters not saved are
usually OK for most situations. It's been reported as a bug and may
be fixed by now.
BUG: As of July 1999 there is a bug/problem in Debian since with
###AUTOSAVE### only the setserial parameters displayed by "setserial
-Gg /dev/ttyS*" get saved but the other parameters don't get saved.
Use the -a flag to "setserial" to see all parameters. This will only
affect a small minority of users since the defaults for the parameters
not saved are usually OK for most situations. It's been reported as a
bug and may be fixed by now.
In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
@ -2670,14 +2740,14 @@ serial hardware supports it. See
If you only have two serial ports, ttyS0 and ttyS1, you're still OK
since IRQ sharing conflicts don't exist for non-existent devices.
If you add an internal modem and retain ttyS0 and ttyS1,
then you should attempt to find an unused IRQ and set it both on your
serial port (or modem card) and then use setserial to assign it to
your device driver. If IRQ 5 is not being used for a sound card, this
may be one you can use for a modem. To set the IRQ in hardware you
may need to use isapnp, a PnP BIOS, or patch Linux to make it PnP. To
help you determine which spare IRQ's you might have, type "man
setserial" and search for say: "IRQ 11".
If you add a legacy internal modem (without plug-and-play) and retain
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
it both on your serial port (or modem card) and then use setserial to
assign it to your device driver. If IRQ 5 is not being used for a
sound card, this may be one you can use for a modem. To set the IRQ
in hardware you may need to use isapnp, a PnP BIOS, or patch Linux to
make it PnP. To help you determine which spare IRQ's you might have,
type "man setserial" and search for say: "IRQ 11".
<sect2> Laptops: PCMCIA <label id="laptops_">
<p>If you have a Laptop, read PCMCIA-HOWTO for info on the serial
@ -4480,11 +4550,17 @@ configuration). Linux supports the bus, although not all devices that
can plug into the bus are supported.
It is synchronous and transmits in special packets like a network.
Just like a network, it can have several devices attached to it. Each
device on it gets a time-slice of exclusive use for a short time. A
device can also be guaranteed the use of the bus at fixed intervals.
One device can monopolize it if no other device wants to use it. It's
not simple to describe in detail.
Just like a network, it can have several devices physically attached
to it, including serial ports. Each device on it gets a time-slice of
exclusive use for a short time. A device can also be guaranteed the
use of the bus at fixed intervals. One device can monopolize it if no
other device wants to use it. It's not simple to describe in detail.
For serial ports on the USB bus, there are numerous configuration
options to use when compiling the kernel. They all start with:
CONFIG_USB_SERIAL. Each one is usually for a certain brand/model of
serial port, although generic is also an option. See the
Configuration Help file in the kernel documentation.
For documentation, see the USB directory in /usr/share/doc/kernel ...
It would be nice to have a HOWTO on the USB. See also <url

549
LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml
View File

@ -1,12 +1,12 @@
<!doctype linuxdoc system>
<article>
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.32, September 2003
<date> v1.33, November 2003
<!--
Change log:
using minicom with directly connected terminals
v1.33 Nov. 2003: revised setserial section
v1.32: Sept. 2003: man page console_codes, name: serial
monitor/console, "init string" rewrite, netrik text browser, new url
for terminfo
@ -190,7 +190,7 @@ url="http://tldp.org/mirrors.html">. Various formats are
available. If you only want to quickly check the date of the latest
version look at <url
url="http://tldp.org/HOWTO/Text-Terminal-HOWTO.html">. The
version your are currently reading is: v1.32, September 2003 .
version your are currently reading is: v1.33, November 2003 .
<sect1>New in Recent Versions:
<p> For a full revision history going back to the first version see
@ -198,7 +198,8 @@ the source file (in linuxdoc format) at <url
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Text-Terminal-HOWTO.sgml.gz">.
<itemize>
v1.32: September 2003: man page console_codes, name: serial
<item>v1.33 Nov. 2003: revised setserial section
<item>v1.32: September 2003: man page console_codes, name: serial
monitor/console, "init string" rewrite, netrik text browser, new url
for terminfo
<item>v1.31 Jan. 2003: more on printer port, error char. appearance,
@ -208,14 +209,7 @@ X-Terminal HOWTO, Hydra date is 1998 (not 1988), edited thin clients
Server (Linux client possible)
<item>v1.29 Mar. 2002: key-switch spring and bending "contact", getty:
Red Hat url, getty: source code -> executable code
<item> v1.28 Jan. 2002:Wyse "manuals" online, fixed a few broken links
<item>v1.27 Nov. 2001: spell checked, more on stuck keys
<item>v1.26 Nov. 2001: text browsers, fixed link to cca.org (was caa.org),
about 20 typos fixed
<item>v1.25 Oct. 2001: Linux Terminal Server Project, bad line in inittab
may cause respawning too rapidly, Evolution of the "terminal server"
had contents in title (my format error), eliminating overstrikes in
files
</itemize>
<sect1> Related HOWTOs, etc. <label id="related_howtos">
@ -512,14 +506,14 @@ their own software or obtain copies of anything.
<sect2> Thin clients and NCs under Linux <label id="linux_thin_clients">
<p> There is a "Linux Terminal Server Project" (LTSP or ltsp) to use
Linux as a server for diskless thin clients. They use X Window and by
default applications run on the server. But with additional effort,
default, applications run on the server. But with additional effort,
one can set it up so that some or all applications run on the
"terminal". See <url url="http://www.ltsp.org/">.
"Terminal" in this name is actually a thin (or fat) client. This
"Terminal" in LTSP is actually a thin (or fat) client. This
project's client can also run a telnet session and thus behave like a
text-terminal. They have created a software package named "lts" which
is available in the major Linux distribution.
text-terminal. A software package named "lts" for the LTSP is
available in the major Linux distributions.
It's claimed that if one has only a few "terminals", they will work
without the ltsp software. But if one has many "terminals", ltsp
@ -1562,10 +1556,10 @@ or the like.
<sect1> Communication (Dialing) programs
<p> Dialing programs for making a PPP connection to the Internet don't
normally include any terminal emulation. But some other modem dialing
programs (such as minicom or seyon) do. Using them one may (for
example) dial up public libraries to use their catalogs and indexes,
(or even read magazine articles). They are also useful for testing
modems. Seyon is only for use with X Window and can emulate
programs (such as minicom or seyon) do. Using them, one may (for
example) dial up some public libraries to use their catalogs and
indexes, (or even read magazine articles). They are also useful for
testing modems. Seyon is only for use with X Window and can emulate
Tektronix 4014 terminals.
The communication program Kermit doesn't do terminal emulation as it
@ -1669,6 +1663,19 @@ available for Linux. The free programs minicom and seyon (only for
X Window) can emulate a vt100 (or close to it). Seyon can also
emulate a Tektronix 4014 terminal.
Minicom may be used to emulate a directly connected terminal by simply
starting minicom (after configuring it for the serial port used). Of
course, you don't dial out and when you want to quit (after you logout
from the other PC) you use the q command to quit without reset since
there is no modem to reset. When minicom starts, it automatically
sends out a modem init string to the serial port. But there's no
modem there and the string gets put after the "login:" prompt. If
this string is mostly capital letters, the getty program (which runs
login) at the other PC may think that your terminal has only capital
letters and try to use only capital letters. To avoid this, configure
the modem init strings sent by minicom to null (erase the init
strings).
The terminal emulator "Procomm" (which is from Dos), can be used on a
Linux PC if you run dosemu to emulate Dos. For details see: <url
url="http://solarflow.dyndns.org/pcplus/">.
@ -1695,11 +1702,13 @@ there is <tt/telix/ and <tt/procomm/. Windows comes with
"HyperTerminal" (formerly simply called "Terminal" in Windows 3.x and
DOS). Competing with this is "HyperTerminal Private Edition" <url
url="http://www.hilgraeve.com/htpe/index.html"> which is non-free to
business. It can emulate vt-220. Turbosoft's TTWin can emulate over
80 different terminals under Windows. See <url
business. It can emulate vt-220. The Windows "terminals" are
intended for calling out with a modem but they should also work as
directly connected terminals?? Turbosoft's TTWin can emulate over 80
different terminals under Windows. See <url
url="http://www.ttwin.com/"> or <url
url="http://www.turbosoft.com.au/"> (Australia).
See also <url url="http://www.wrq.com/" name="Reflection">
url="http://www.turbosoft.com.au/"> (Australia). See also <url
url="http://www.wrq.com/" name="Reflection">
For the Mac Computer there is emulation by Carnation Software <url
url="http://www.carnationsoftware.com/carnation/HT.Carn.Home.html">
@ -2357,14 +2366,14 @@ second time again. Sometimes the first login would be automatic, or
perhaps there would be a choice given the user as to what host
computer (or printer) to connect to (or what protocol to use).
The use of text-terminals declined as the PC replaced mainframes.
The use of real text-terminals declined as the PC replaced mainframes.
But the PC could emulate a terminal (using say minicom (Linux) or
(hyper)terminal for MS). One could could then dial-out via a
modem to a bulletin-board or the like. There would be a bank of
modems to accept such calls and each modem would be connected to a
serial port. The serial port could either be on a multiport card or
on a dedicated terminal server. Note that in both the above cases
there is no client software. It's not a client-server model.
(hyper)terminal for MS). One could could then dial-out via a modem
to a bulletin-board or the like. There would be a bank of modems to
accept such calls and each modem would be connected to a serial port.
The serial port could either be on a multiport card or on a dedicated
terminal server. Note that in both the above cases there is no client
software. It's not a client-server model.
When the Internet became popular, one would run the PPP protocol on
the phone line and still go thru a modem and "terminal server" at the
@ -3796,67 +3805,103 @@ Nov. 2000: auto_irq may work on the 2nd try
Dec. 2000: saving state of serial module
June 2001 OK to use setserial with Laptops
Nov. 2002 Debian's /var/lib/serial.conf
Nov. 2003 Major revision, since today, plug-and-play dominates
/var/lib/setserial/autoserial.conf
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
<sect2> Introduction
<sect2>Important information
<p>
If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
read <ref id="laptops_" name="Laptops: PCMCIA">. <tt/setserial/ is a
program which allows you to tell the device driver software the I/O
address of the serial port, which interrupt (IRQ) is set in the port's
hardware, what type of UART you have, etc. Since there's a good
chance that the serial ports will be automatically detected and set,
many people never need to use <tt/setserial/. In any case setserial
will not work without either serial support built into the kernel or
loaded as a module. The module may get loaded automatically if you
(or a script) tries to use setserial.
read <ref id="laptops_" name="Laptops: PCMCIA">.
Setserial can also show how the driver is currently set. In addition,
it can be made to probe the hardware I0 port addresses to try to
determine the UART type and IRQ, but this has severe limitations. See
<ref id="probing_ss" name="Probing">. Note that it can't set the IRQ
or the port address in the hardware of PnP serial ports (but the
plug-and-play features of the serial driver may do this). It can't
read the PnP data stored in configuration registers in the hardware.
The term PnP means Plug-and-Play. All serial ports on the PCI bus are
PnP and many on the ISA bus are also PnP. Linux software with the
term "pnp" in it is usually only for the ISA bus. The PCI bus is
inherently PnP so sofware for dealing with PnP on the PCI bus
usually contains the term "pci" but not "pnp".
If you only have one or two built-in serial ports, they will usually
get set up correctly without using setserial. Otherwise, if you add
more serial ports (such as a modem card) you may need to deal with
setserial. Besides the man page for <tt/setserial/, check out info in
<sect2> Introduction
<p><tt/setserial/ is a program which allows you (or a shell script) to
talk to the serial device driver software. You may use it to tell the
device driver how the hardware is phsically set (I/O addrees, IRQ,
etc.). But normally, the device drivers finds out this infomation
itself so that you don't need to use <tt/setserial/. But if the device
driver can't find a serial port (or perhaps gets the IRQ wrong) and
you can find out this infomation while the driver can't, then
<tt/setserial/ is essential. How to find serial ports is covered
elsewhere, and in a minority of cases, <tt/setserial/ will be useful
to help find them.
<tt/setserial/ permits you (or a script) to configure the serial port
by telling the device driver the I/O address of the serial port, which
interrupt (IRQ) is set in the port's hardware, what type of UART you
have, etc. The name <tt/setserial/ is somewhat of a misnomer since it
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
them in the driver software. And the driver naively believes that
what <tt/setserial/ tells it has already been set in the hardware.
Since the device driver is considered to be part of the kernel, the
word "kernel" is often used in other documentation with no mention
made of any "serial driver".
Some distributions (and versions) set things up so that <tt/setserial/ is
run at boot-time by an initialization shell script (usually in the
/etc directory tree). In other cases, you have to take some action to
run <tt/setserial/ at boot-time. <tt/setserial/ will not work without
either serial support built into the kernel or loaded as a module.
The module may get loaded automatically if you (or a script) attempt
to use setserial.
In addition to using <tt/setserial/ to configure, <tt/setserial/ can
show you how the driver is currently configured (set). Hopefully, the
hardware is set the same. In addition, it can be made to probe the
hardware I0 port addresses to try to determine the UART type and IRQ,
but this has severe limitations. See <ref id="probing_ss"
name="Probing">. Note that it can't set the IRQ or the port address
in the hardware of PnP serial ports (but the plug-and-play features of
the serial driver may do this). It also can't directly read the PnP
data stored in configuration registers in the hardware. But since the
device driver can read these registers, <tt/setserial/ could be
telling you what's in them, or it could be telling you what
<tt/setserial/ had previously (and perhaps erroneously) told the
driver. There's no way to know for sure without doing some other
checks.
The serial driver (for Linux 2.4+) looks for a few "standard" legacy
serial ports, for PnP ports on the ISA bus, and for all supported port
hardware on the PCI bus. If it finds these OK then there's no need to
use <tt/setserial/. The driver doesn't probe for legacy IRQs and may
get these wrong.
Besides the man page for <tt/setserial/, check out info in
<tt>/usr/doc/setserial.../</tt> or <tt>/usr/share/doc/setserial</tt>.
It should tell you how setserial is handled in your distribution of
Linux.
<tt/Setserial/ is often run automatically at boot-time by a start-up
shell-script for the purpose of assigning IRQs, etc. to the driver.
Setserial will only work if the serial module is loaded (or if the
equivalent was compiled into your kernel). If the serial module gets
unloaded later on, the changes previously made by <tt/setserial/ will
be forgotten by the kernel. But recent (2000) distributions may
contain scripts that save and restore this. If not, then
<tt/setserial/ must be run again to reestablish them. In addition to
running via a start-up script, something akin to <tt/setserial/ also
runs earlier when the serial module is loaded (or the like). Thus
when you watch the start-up messages on the screen it may look like it
ran twice, and in fact it has.
Setserial can set the time that the port will keep operating after
it's closed (in order to output any characters still in its buffer in
main RAM). This is needed at slow baud rates of 1200 or lower. It's
also needed at higher speeds if there are a lot of "flow control"
waits. See "closing_wait" in the setserial man page.
If your serial port is Plug-and-Play you may need to consult other
Linux. While <tt/setserial/ behaves the same in all distributions,
the scripts for running it, how to configure such scripts (including
automatic configuration), and the names and locations of the script
files, etc., are all distribution-dependent. If your serial port is Plug-and-Play you may need to consult other
HOWTOs such as Plug-and-Play or Serial.
Setserial does not set either IRQ's nor I/O addresses in the serial
port hardware itself. That is done either by jumpers or by
plug-and-play. You must tell setserial the identical values that have
been set in the hardware. Do not just invent some values that you
think would be nice to use and then tell them to setserial. However,
if you know the I/O address but don't know the IRQ you may command
setserial to attempt to determine the IRQ.
<sect2>Serial module unload
<p>If a serial module gets unloaded, the changes previously made by
<tt/setserial/ will be forgotten by the driver. But while the driver
forgets it, a script provided by the distribution may save it in a
file somewhere so that it can the restored if the module is reloaded.
<sect2>Giving the <tt/setserial/ command
<p>Remember, that <tt/setserial/ can't set any I/O addresses or IRQs
in the hardware. That's done either by plug-and-play software (run by
the driver) or by jumpers for legacy serial ports. Even if you give
an I/O address or IRQ to the driver via <tt/setserial/ it will not set
such values and assumes that they have already been set. If you give
it wrong values, the serial port will not work right (if at all).
For legacy ports, if you know the I/O address but don't know the IRQ
you may command setserial to attempt to determine the IRQ.
You can see a list of possible commands by just typing <tt/setserial/
with no arguments. This fails to show you the one-letter options such
@ -3865,9 +3910,9 @@ Note that setserial calls an IO address a "port". If you type:
<tscreen><verb>
setserial -g /dev/ttyS*
</verb></tscreen>
you'll see some info about how that device driver is configured for
you'll see some info about how the device driver is configured for
your ports. Note that where it says <tt>"UART: unknown"</tt> it
probably means that no uart exists. In other words you probably have
probably means that no uart exists. In other words, you probably have
no such serial port and the other info shown about the port is
meaningless and should be ignored. If you really do have such a
serial port, setserial doesn't recognize it and that needs to be
@ -3876,40 +3921,61 @@ fixed.
If you add -a to the option -g you will see more info although few
people need to deal with (or understand) this additional info since
the default settings you see usually work fine. In normal cases the
hardware is set up the same way as "setserial" reports, but if you are
having problems there is a good chance that "setserial" has it wrong.
hardware is set up the same way as "setserial" reports. But if you are
having problems there is a good chance that <tt/setserial/ has it wrong.
In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. They will also be officially
bogus values you've supplied to the driver. They will also be officially
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command (Debian). Of course the serial
port driver will not work correctly (if at all) if you attempt to use
such a port. Thus when giving parameters to "setserial" anything
goes. Well almost. If you assign one port a base address that is
such a port. Thus, when giving parameters to <tt/setserial/, "anything
goes". Well almost. If you assign one port a base address that is
already assigned (such as 3e8) it may not accept it. But if you use
3e9 it will accept it. Unfortunately 3e9 is already assigned since it
3e9 it will accept it. Unfortunately 3e9 is actually assigned since it
is within the range starting at base address 3e8. Thus the moral of
the story is to make sure your data is correct before assigning
resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
configuration) when the PC is started up again. In newer versions,
what you change by setserial may get automatically saved to a
configuration file. In older versions, the configuration file only
changes if you edit it manually so the configuration always remains
the same from boot to boot. See <ref id="ss_conf_script"
name="Configuration Scripts/Files">
<sect2>Configuration file
<p>While assignments made by setserial are lost when the PC is powered
off, a configuration file usually restores them when the PC is started
up again. In newer versions, what you change by setserial might get
automatically saved to a configuration file. When <tt/setserial/ runs
it uses the info from the the configuration file. In Debian there are
4 options for use of this configuration file:
<enum>
<item>Don't use this file at all. At each boot, the serial driver
alone detects the ports and setserial doesn't ever run. ("kernel" option)
<item>Save what <tt/setserial/ reports when the system is first
shutdown and put it in the configuration file. After that, don't ever
make any changes to the configuration file, even if someone has made
changes by running the <tt/setserial/ command on the command line and
then shuts down the system. ("autosave-once" option)
<item>At every shutdown, save whatever <tt/setserial/ detects to the
configuration file. ("autosave" option)
<item>Manually edit the configuration file to set the configuration.
Don't ever do any automatic saves to it. ("manual" option)
</enum>
In old versions (perhaps before 2000), there wasn't any configuration
file and the configuration was manually set (hard coded) inside the
shell script that ran <tt/setserial/. See <ref id="old_sets_script"
name="Edit a script (prior to version 2.15)">.
<sect2> Probing <label id="probing_ss">
<p>Prior to probing with "setserial", one may run the "scanport"
(Debian) command to check all possible ports in one scan. It makes
crude guesses as to what is on some ports but doesn't determine the
IRQ. But it's a fast first start. It may hang your PC but so far
it's worked fine for me. Note that non-Debian distributions don't
seem to supply "scanport". Is there an another scan program?
<p>You probe for a port only when you suspect that it has been enabled
(by PnP methods ,the BIOS, jumbers, etc.), otherwise setserial probing
will never find it since its address doesn't exist. Probling is where
the software looks for a port at specified I/O addresses. Prior to
probing with "setserial", one may run the "scanport" (Debian) command
to check all possible ports in one scan. It makes crude guesses as to
what is on some ports but doesn't determine the IRQ. It's a fast
first start. It may hang your PC but so far it's worked fine for me.
Note that non-Debian distributions don't seem to supply "scanport".
Is there another scan program?
With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
@ -3918,181 +3984,173 @@ address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
is at a different address, then it will probe at that address, etc.
See <ref id="probing_ss" name="Probing">
The purpose of this is to see if there is a uart there, and if so,
what its IRQ is. Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using <tt>pnpdump
The purpose of such probing is to see if there is a uart there, and if
so, what its IRQ is. Use <tt/setserial/ mainly as a last resort as
there are faster ways to attempt it such as wvdialconf to detect
modems, looking at very early boot-time messages, or using <tt>pnpdump
--dumpregs</tt>. To try to detect the physical hardware use for
example :<newline>
<tt>setserial /dev/ttyS2 -v autoconfig</tt><newline>
If the resulting message shows a uart type such as 16550A, then you're
OK. If instead it shows "<tt/unknown/" for the uart type, then there
is supposedly no serial port at all at that I/O address. Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.
example :<newline> <tt>setserial /dev/ttyS2 -v
autoconfig</tt><newline> If the resulting message shows a uart type
such as 16550A, then you're OK. If instead it shows "<tt/unknown/"
for the uart type, then there is supposedly no serial port at all at
that I/O address. Some cheap serial ports don't identify themselves
correctly so if you see "<tt/unknown/" you still might have a serial
port there.
Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically saved and put into the
configuration file <tt>/etc/serial.conf</tt> or
<tt>/var/lib/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
last probe test could be automatically saved and put into a
configuration file such as <tt>/etc/serial.conf</tt> or
<tt>/var/lib/setserial/autoserial.conf</tt>. This will be used next
time you start Linux.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
happens anyway. Probing detects one serial port when actually there
are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
<tt/setserial/ to give the IRQ a fictitious value.
the hardware. Of course this is not normally permitted for the ISA
bus but it sometimes happens anyway. Probing detects one serial port
when actually there are two. However if they have different IRQs,
then the probe for IRQs may show IRQ = 0. For me, it only did this if
I first used <tt/setserial/ to give the IRQ a fictitious value.
<sect2>Boot-time Configuration <label id="sets_boot_time">
<p>While <tt/setserial/ may run via an initialization script,
something akin to <tt/setserial/ also runs earlier when the serial
module is loaded (or when the kernel starts the built-in serial driver
if it was compiled into the kernel). Thus when you watch the start-up
messages on the screen it may look like it ran twice, and in fact it
has.
<sect2> Boot-time Configuration <label id="sets_boot_time">
<p> When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
auto-detected and the driver is set to use only IRQs 4 and 3
(regardless of what IRQs are actually set in the hardware). You see
this as a boot-time message just like as if <tt/setserial/ had been
run.
But the IRQs shown may be wrong since it doesn't probe for IRQs. The
second report of the same is the result of a script such as
/etc/init.d/setserial. It usually does no probing and thus could be
wrong about how the hardware is actually set. It only shows
configuration data that got saved in a configuration files. The old
method, prior to setserial 2.15, was to manually write such data
directly into the script.
To correct possible errors in IRQs (or for other reasons) there may be
a file somewhere that runs <tt/setserial/ again. Unfortunately, if
this file has some IRQs wrong, the kernel will still have incorrect
info about the IRQs. This file should run early at boot-time before
any process uses the serial port. In fact, your distribution may have
set things up so that the setserial program runs automatically from a
start-up script at boot-time. More info about how to handle this
situation for your particular distribution might be found in file
named "setserial..." or the like located in directory /usr/doc/ or
/usr/share/doc/.
When the kernel loads the serial module (or if the "module equivalent"
is built into the kernel) then all supported PnP ports are detected.
For legacy (non-PnP) ports, only <tt/ttyS{0-3}/ are auto-detected
and the driver is set to use only IRQs 4 and 3 (regardless of what
IRQs are actually set in the hardware). No probing is done for IRQs
but it's possible to do this manually. You see this as a boot-time
message just as if <tt/setserial/ had been run.
For legacy ports, to correct possible errors in IRQs (or for other
reasons) there is likely a script file somewhere that runs
<tt/setserial/ again. Unfortunately, if this file has some IRQs
wrong, the kernel will still have incorrect info about the IRQs. This
file is usually part of the initialization done at boot-time and
whether it runs or not depends on how you (and/or your distribution)
have set up the running to these initialization scripts. It also
depends on the runlevel.
Before modifying a configuration file, you can test out a "proposed"
<tt/setserial/ command by just typing it on the command line. In some
cases the results of this use of <tt/setserial/ will automatically get
saved in /etc/serial.conf when you shutdown. So if it worked OK (and
solved your problem) then there's no need to modify any configuration
file. See <ref id="new_config" name="New configuration method using
/etc/serial.conf">.
<sect2> Configuration Scripts/Files <label id="ss_conf_script">
<p> Your objective is to modify (or create) a script file in the /etc
tree that runs setserial at boot-time. Most distributions provide
such a file (but it may not initially reside in the /etc tree). In
addition, setserial 2.15 and higher often have an /etc/serial.conf
file that is used by the above script so that you don't need to
directly edit the script that runs setserial. In addition just using
setserial on the command line (2.15+) may ultimately alter this
configuration file.
So prior to version 2.15 all you do is edit a script. After 2.15 you
may need to either do one of three things: 1. edit a script. 2. edit
<tt>/etc/serial.conf</tt> or 3. run "setserial" on the command line
which may result in <tt>/etc/serial.conf</tt> automatically being
edited. Which one of these you need to do depends on both your
particular distribution, and how you have set it up.
file. See <ref id="config_file" name="Configuration method using
/etc/serial.conf, etc.">.
<sect2> Edit a script (required prior to version 2.15)
<label id="old_sets_script">
<p> Prior to setserial 2.15 (1999) there was no /etc/serial.conf file
to configure setserial. Thus you need to find the file that runs
"setserial" at boot time and edit it. If it doesn't exist, you need
to create one (or place the commands in a file that runs early at
boot-time). If such a file is currently being used it's likely
somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
<p> This is how it was done prior to <tt/setserial/ 2.15 (1999)
The objective was to modify (or create) a script file in the /etc
tree that runs setserial at boot-time. Most distributions provided
such a file (but it may not have initially resided in the /etc tree).
So prior to version 2.15 (1999) it was simpler. All you did was edit
a script. There was no /etc/serial.conf file (or the like) to
configure setserial. Thus you needed to find the file that runs
"setserial" at boot time and edit it. If it didn't exist, you needed
to create one (or place the commands in a file that ran early at
boot-time). If such a file was currently being used it's likely
was somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
in /usr/doc/setserial/ but you need to move it to the /etc tree before
using it. You might use "locate" to try to find such a file. For
example, you could type: locate "*serial*".
using it.
The script <tt>/etc/rc.d/rc.serial</tt> was commonly used in the past.
The Debian distribution used <tt>/etc/rc.boot/0setserial</tt>.
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's
not a good idea to use this since it may not be run early enough.
It's been reported that other processes may try to open the serial
port before rc.local runs resulting in serial communication failure.
Today it's most likely in /etc/init.d/ but it isn't normally intended
to be edited.
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's may
not have run early enough. It's was reported that other processes may
try to open the serial port before rc.local ran resulting in serial
communication failure. Later on it's most likely was found in
/etc/init.d/ but wasn't normally intended to be edited.
If such a file is supplied, it should contain a number of
If such a file was supplied, it likely contained a number of
commented-out examples. By uncommenting some of these and/or
modifying them, you should be able to set things up correctly. Make
sure that you are using a valid path for <tt/setserial/, and a valid
modifying them, you could set things up correctly. It was important
use a valid path for <tt/setserial/, and a valid
device name. You could do a test by executing this file manually
(just type its name as the super-user) to see if it works right.
Testing like this is a lot faster than doing repeated reboots to get
Testing like this was a lot faster than doing repeated reboots to get
it right.
For versions >= 2.15 (provided your distribution implemented the
change, Redhat didn't) it may be more tricky to do since the file that
runs setserial on startup, /etc/init.d/setserial or the like was not
intended to be edited by the user. See <ref id="new_config"
name="New configuration method using /etc/serial.conf">.
If you want setserial to automatically determine the uart and the IRQ
for ttyS3 you would add something like:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
Do this for every serial port you want to auto configure. Be sure to
give a device name that really does exist on your machine. In some
cases this will not work right due to the hardware. If you know what
the uart and irq actually are, you may want to assign them explicitly
with "setserial". For example:
intended to be edited by the user. See <ref id="config_file"
name="Configuration method using /etc/serial.conf, etc.">.
An example line in such a script was"
<tscreen><verb>
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
</verb></tscreen>
or, if you wanted setserial to automatically determine the uart and the
IRQ for ttyS3 you would have used something like this:
<sect2> New configuration method using /etc/serial.conf
<label id="new_config">
<p> Prior to setserial version 2.15, the way to configure setserial
<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
This was done for every serial port you wanted to auto configure,
using a device name that really does exist on your machine. In some
cases it didn't work right due to the hardware.
<sect2> Configuration method using /etc/serial.conf, etc.
<label id="config_file">
<p> Prior to setserial version 2.15 (1999), the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
See <ref id="old_sets_script" name="Edit a script (after version 2.15:
perhaps not)">. Starting with version 2.15 (1999) of <tt/setserial/
this shell-script is not edited but instead gets its data from a
configuration file: <tt>/etc/serial.conf</tt>. Furthermore you may
not even need to edit serial.conf because using the "setserial"
command on the command line may automatically cause serial.conf to be
edited appropriately.
See <ref id="old_sets_script" name="Edit a script (before version
2.15)">. Today the script and configuration file are two different
files instead of one. This shell-script is not edited but gets its
data from a configuration file such as <tt>/etc/serial.conf</tt>.
This was intended so that you don't need to edit any file in order to
Furthermore you may not even need to edit serial.conf because using
the "setserial" command on the command line may automatically cause
serial.conf to be edited appropriately.
This was done so that you don't need to edit any file in order to
set up (or change) what setserial does each time that Linux is booted.
But there are serious pitfalls because it's not really "setserial"
that edits serial.conf. Confusion is compounded because different
distributions handle this differently. In addition, you may modify it
so that it works differently.
What often happens is this: When you shut down your PC the script
that runs "setserial" at boot-time is run again, but this time it only
that ran "setserial" at boot-time is run again, but this time it only
does what the part for the "stop" case says to do: It uses
"setserial" to find out what the current state of "setserial" is, and
it puts that info into the <tt>serial.conf</tt> file. Thus when you
run "setserial" to change the serial.conf file, it doesn't get changed
immediately but only when and if you shut down normally.
it puts that info into the serial configuration file such as
<tt>serial.conf</tt>. Thus when you run "setserial" to change
the serial.conf file, it doesn't get changed immediately but only when
and if you shut down normally.
Now you can perhaps guess what problems might occur. Suppose you
don't shut down normally (someone turns the power off, etc.) and the
changes don't get saved. Suppose you experiment with "setserial" and
forget to run it a final time to restore the original state (or make a
mistake in restoring the original state). Then your "experimental"
settings are saved.
settings are saved. There's an option to avoid this in Debian known
as "AUTOSAVE-ONCE" which will be discussed later on.
If you manually edit serial.conf, then your editing is destroyed when
you shut down because it gets changed back to the state of setserial
at shutdown. There is a way to disable the changing of serial.conf at
shutdown and that is to remove "###AUTOSAVE###" or the like from first
line of serial.conf. In at least one distribution, the removal of
"###AUTOSAVE###" from the first line is automatically done after the
first time you shutdown just after installation. The serial.conf file
should contain some comments to explain this.
line of serial.conf. In the Debian distribution, the removal of
"###AUTOSAVE###" from the first line was once automatically done after
the first time you shutdown just after installation. To retain this
effect the "AUTOSAVE-ONCE" option was created which only saves the
first time the system is shut down.
The file most commonly used to run setserial at boot-time (in
conformance with the configuration file) is now /etc/init.d/setserial
@ -4101,19 +4159,19 @@ normally be edited. For 2.15, Redhat 6.0 just had a file
/usr/doc/setserial-2.15/rc.serial which you have to move to
/etc/init.d/ if you want setserial to run at boot-time.
To disable a port, use <tt/setserial/ to set it to
"uart none". The format of /etc/serial.conf appears to be just like
that of the parameters placed after "setserial" on the command line
with one line for each port. If you don't use autosave, you may edit
/etc/serial.conf manually.
To disable a port, use <tt/setserial/ to set it to "uart none". This
will not be saved. The format of /etc/serial.conf appears to be just
like that of the parameters placed after "setserial" on the command
line with one line for each port. If you don't use autosave, you may
edit /etc/serial.conf manually.
BUG: As of July 1999 there is a bug/problem since with ###AUTOSAVE###
only the setserial parameters displayed by "setserial -Gg /dev/ttyS*"
get saved but the other parameters don't get saved. Use the -a flag
to "setserial" to see all parameters. This will only affect a small
minority of users since the defaults for the parameters not saved are
usually OK for most situations. It's been reported as a bug and may
be fixed by now.
BUG: As of July 1999 there is a bug/problem in Debian since with
###AUTOSAVE### only the setserial parameters displayed by "setserial
-Gg /dev/ttyS*" get saved but the other parameters don't get saved.
Use the -a flag to "setserial" to see all parameters. This will only
affect a small minority of users since the defaults for the parameters
not saved are usually OK for most situations. It's been reported as a
bug and may be fixed by now.
In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
@ -4138,14 +4196,14 @@ Serial-HOWTO: Interrupt sharing and Kernels 2.2+.
If you only have two serial ports, ttyS0 and ttyS1, you're still OK
since IRQ sharing conflicts don't exist for non-existent devices.
If you add an internal modem and retain ttyS0 and ttyS1,
then you should attempt to find an unused IRQ and set it both on your
serial port (or modem card) and then use setserial to assign it to
your device driver. If IRQ 5 is not being used for a sound card, this
may be one you can use for a modem. To set the IRQ in hardware you
may need to use isapnp, a PnP BIOS, or patch Linux to make it PnP. To
help you determine which spare IRQ's you might have, type "man
setserial" and search for say: "IRQ 11".
If you add a legacy internal modem (without plug-and-play) and retain
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
it both on your serial port (or modem card) and then use setserial to
assign it to your device driver. If IRQ 5 is not being used for a
sound card, this may be one you can use for a modem. To set the IRQ
in hardware you may need to use isapnp, a PnP BIOS, or patch Linux to
make it PnP. To help you determine which spare IRQ's you might have,
type "man setserial" and search for say: "IRQ 11".
<sect2> Laptops: PCMCIA <label id="laptops_">
<p>If you have a Laptop, read PCMCIA-HOWTO for info on the serial
@ -5440,11 +5498,15 @@ for lilo.conf and search for "serial=".
<sect1> Run Linux without a Monitor
<p> One way to do this is to just use a terminal (serial console) for
the monitor See <ref id="term_as_console" name="Make a Serial Terminal
the Console">. You will likely still need a video card since most
BIOSs require one to get the PC started. Your BIOS may also require a
the Console">. You may still need a video card since many BIOSs
require one to get the PC started. Your BIOS may also require a
keyboard to get started or it may have an option where you can set the
BIOS not to require a keyboard.
If you boot without a monitor, make sure that the boot loader (such as
LILO or GRUB) doesn't try to present any image on the screen. A
text-terminal can't display it and the booting may hang.
If you have a keyboardless terminal, it can also be used as a monitor
by use of the ttysnoop program. As of yet, it doesn't work like a
console since it doesn't get all the initial boot-time messages. See
@ -7361,4 +7423,3 @@ the set-up (confusing menu design).
END OF Text-Terminal-HOWTO
</article>