This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There are some minor differences, depending on which HOWTO it appears in.
If you have a Laptop (PCMCIA) don't use setserial until you
read
Laptops: PCMCIA. 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 theres a good chance
that the serial ports will be automatically detected and set, many
people never need to use 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.
Setserial can also show how the driver is currently set. In addition, it can be made to probe the hardware and try to determine the UART type and IRQ, but this has severe limitations. See 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).
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 will likely need to deal
with setserial. Besides the man page for setserial, check out
info in /usr/doc/setserial.../ or
/usr/share/doc/setserial. It should tell you how setserial
is handled in your distribution of Linux.
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 setserial will
be forgotten by the kernel. But recent (2000) distributions may
contain scripts that save and restore this. If not, then
setserial must be run again to reestablish them. In addition to
running via a start-up script, something akin to 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 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.
You can see a list of possible commands by just typing setserial
with no arguments. This fails to show you the one-letter options such
as -v for verbose which you should normally use when troubleshooting.
Note that setserial calls an IO address a "port". If you type:
setserial -g /dev/ttyS*
"UART: unknown" it
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
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. 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 registered with the kernel as displayed (at the top of the screen) by the "scanport" command. 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 already assigned (such as 3e8) it will not accept it. But if you use 3e9 it will accept it. Unfortunately 3e9 is already 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 Configuration Scripts/Files
Prior to probing with "setserial", one may run the "scanport" 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.
With appropriate options, setserial can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
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
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 pnpdump
--dumpregs. To try to detect the physical hardware use for
example :
setserial /dev/ttyS2 -v autoconfig
If the resulting message shows a uart type such as 16550A, then you're
OK. If instead it shows "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
"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 /etc/serial.conf 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.
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
setserial to give the IRQ a ficticious value.
When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only 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 setserial had been
run.
To correct possible errors in IRQs (or for other reasons) there may be
a file somewhere that runs 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/.
Before modifying a configuration file, you can test out a "proposed"
setserial command by just typing it on the command line. In some
cases the results of this use of 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
New configuration method using /etc/serial.conf.
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
/etc/serial.conf or 3. run "setserial" on the command line
which may result in /etc/serial.conf automatically being
edited. Which one of these you need to do depends on both your
particular distribution, and how you have set it up.
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 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*".
The script /etc/rc.d/rc.serial was commonly used in the past.
The Debian distribution used /etc/rc.boot/0setserial.
Another file once used was /etc/rc.d/rc.local 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.
If such a file is supplied, it should contain 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 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
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 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:
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
Prior to setserial version 2.15, the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
See
Edit a script (after version 2.15: perhaps not). Starting with version 2.15 (1999) of setserial
this shell-script is not edited but instead gets its data from a
configuration file: /etc/serial.conf. 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 intended 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
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 serial.conf 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.
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.
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.
The file most commonly used to run setserial at boot-time (in conformance with the configuration file) is now /etc/init.d/setserial (Debian) or /etc/init.d/serial (Redhat), or etc., but it should not 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 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.
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.
In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
normally happens when you shutdown: Run the shell-script
/etc/init.d/{set}serial stop. The "stop" command will save
the current configuration but the serial ports still keep working OK.
In some cases you may wind up with both the old and new configuration methods installed but hopefully only one of them runs at boot-time. Debian labeled obsolete files with "...pre-2.15".
By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and ttyS3 share IRQ 3. But actually sharing serial interrupts (using them in running programs) is not permitted unless you: 1. have kernel 2.2 or better, and 2. you've complied in support for this, and 3. your serial hardware supports it. See
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 have a Laptop, read PCMCIA-HOWTO for info on the serial configuration. For serial ports on the motherboard, setserial is used just like it is for a desktop. But for PCMCIA cards (such as a modem) it's a different story. The configuring of the PCMCIA system should automatically run setserial so you shouldn't need to run it. If you you do run it (by a script file or by /etc/serial.conf) it might be different and cause trouble. The autosave feature for serial.conf shouldn't save anything for PCMCIA cards (but Debian did until 2.15-7). Of course, it's always OK to use setserial to find out how the driver is configured for PCMCIA cards.
isapnp is a program to configure Plug-and-Play (PnP) devices
on the ISA bus including internal modems. It comes in a package
called "isapnptools" and includes another program, "pnpdump" which
finds all your ISA PnP devices and shows you options for configuring
them in a format which may be added to the PnP configuration file:
/etc/isapnp.conf. It may also be used with the --dumpregs option to
show the current IO address and IRQ of the modem's serial port. The
isapnp command may be put into a startup file so that it runs each
time you start the computer and thus will configure ISA PnP devices.
It is able to do this even if your BIOS doesn't support PnP. See
Plug-and-Play-HOWTO.
wvdialconf will try to find which serial port (ttyS?) has a
modem on it. It also creates a configuration program for the wvdial
program. wvdial is used for simplified dialing out using the PPP
protocol to an ISP. But you don't need to install PPP in order to use
wvdialconf. It will only find modems which are not in use. It
will also automatically devise a "suitable" init strings but sometimes
gets it wrong. Since this command has no options, it's simple to use
but you must give it the name of a file to put the init string (and
other data) into. For example type: wvdialconf my_config_file_name.
stty is like setserial but it sets the baud rate, hardware
flow control, and other parameters of a serial port. Typing "stty -a
< /dev/ttyS2" should show you how ttyS2 is configured. Most of the
settings are for things that you never need to use with modems (such
as some used only for old terminals of the 1970s). Your communication
package should automatically set up all these settings correctly for
modems. For this reason you normally don't need to use stty so it's
not covered much in this Modem-HOWTO. But stty is sometimes
useful for trouble-shooting. More is said about stty in the
Serial-HOWTO or Text-Terminal-HOWTO..
Two items set by stty are: 1. Hardware flow control by "crtscts" and 2. Ignore the CD signal from the modem: "clocal". If the modem is not sending a CD signal and clocal is disabled (stty shows -clocal) then a program may not be able to open the serial port. If the port can't open, the program may just hang, waiting (often in vain) for a CD signal from the modem.
Minicom sets clocal automatically when it starts up so there is no problem. But version 6.0.192 of Kermit hung when I set -clocal and tried to "set line ..." If -clocal is set and there is no CD signal then even the "stty" command will hang and there is seemingly no way to set clocal (except by running minicom). But minicom will restore -clocal when it exits. One way to get out of this is to use minicom to send the "AT&C" to the modem (to get the CD signal) and then exit minicom with no reset so that the CD signal always remains on. Then you may use stty again. CD always-on is fine for dial-out but dial-in may not work right.