Don't ever use setserial with 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. It can
also show how the driver is currently set. In addition, it can probe
the hardware (if certain options are given).
If you only have one or two serial ports, they will usually get set up
correctly without using setserial. Otherwise (or if there are
problems with the serial port) you will likely need to deal with
setserial. Besides the manual for setserial, check out info in
/usr/doc/setserial.../ or the like. 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. It will only work if the serial module is loaded. If
you should for some reason unload the serial module later on, the
changes previously made by setserial will be forgotten by the
kernel (but not by /etc/serial.conf). So setserial must be run
again to reestablish them. In addition to running via a start-up
script, something akin to setserial runs when the serial module
is loaded. Thus when you watch the start-up messages on the screen it
may look like it ran twice, and in fact it has.
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. If you tell setserial that ttyS2 is at
a different address, then it will probe at that address, etc. See
Probing
Setserial does not set either IRQ's nor I/O addresses in the serial port hardware itself. It's set in the hardware either by jumpers or by plug-and-play. You must tell setserial these 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 to use (but not the one-letter
options such as -v for verbose --which you should normally use when
troubleshooting) by just typing setserial with no arguments.
Note that setserial calls an I/O address a "port". If you type:
setserial-g /dev/ttyS*you'll see some info about how that device driver is configured for your ports. Add a "v" to the option "-g" to see more. But this doesn't tell you if the hardware actually has these values set in it. If fact, you can run setserial and assign a purely fictitious I/O 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. Note that assignments made by setserial are lost when the PC is powered down so it is usually run automatically somewhere each time that Linux is booted.
In order to try to find out if you have a certain piece of serial
hardware you must first know (or guess) its I/O address (or the device driver
must have an I/O address for it, likely previously set by setserial).
To try to detect the physical hardware use the -v (verbose) and
autoconfig command to setserial. 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 uart type, setserial can auto-probe for IRQ's
but this doesn't always work right either. In versions of setserial
>= 2.15, your last probe test may be saved and put into the
configuration file /etc/serial.conf which will be used next
time you start Linux. The script that runs setserial at
boot-time does not usually probe, but you could change it so that it
does. See the next section.
Yes, but ... Your distribution may already do this on startup. But you may want to customize it. It's easy to do for setserial < 2.15. Just add some lines to the file that runs setserial on start-up. See Old configuration method: edit a script For example, for ttyS3 you would add:
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
For versions >= 2.15 (provided your distribution implemented the change, Redhat didn't) it's much harder 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. There may be no helpful comments in it like there were in earlier versions.
When the kernel loads the serial module (or if the "module" is
built into the kernel) then only ttyS{0-3} are auto-detected and
the driver is set to IRQs 4 and 3 (regardless of what the hardware is
actually set at). You see this as a boot-time message just like as if
setserial had been run.. If you use 3 or more ports, this may
result in IRQ conflicts.
To fix such conflicts by telling setserial the true IRQs (or for other
reasons) there may be a file somewhere that runs setserial again.
This happens 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 should be
found in /usr/doc/setserial.../ or the like.
Prior to setserial version 2.15, the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
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 not even serial.conf is intended to be
edited. Instead just use setserial on the command line.
Normally, what you changed with the setserial command is saved to the
configuration file (serial.conf) when you shutdown (normally) or
reboot. This only works if "###AUTOSAVE### or the like is on the
first line of serial.conf. If you should use setserial
experimentally and it doesn't work out right, then don't forget to
redo it so that the experimental settings don't get saved by mistake.
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 also should
not normally be edited.
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. For 2.15, the Debian distribution installs
the system with autosave enabled, but Redhat 6.0 just had a file
/usr/doc/setserial-2.15/rc.serial which you have to move to
/etc/init.d/.
BUG: As of July 1999 there is a bug/problem since with ###AUTOSAVE### only the setserial parameters displayed by "setserial -G /dev/ttyS?" (where ? = 0, 1, 2, ...) get saved but the other parameters don't get saved. This will only affect a small minority of users since the parameters not saved are seldom used anyway. 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.
I 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".
Prior to 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/ although 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*".
What you are looking for could be named rc.serial, or 0setserial
(Debian). 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. Of course you can also test a single setserial command
by just typing it on the command line.
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 is /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.
By default, both ttyS0 and ttyS2 share IRQ 4, while ttyS0 and ttyS3 share IRQ 3. But sharing serial interrupts 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".
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 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 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 the setting correctly for modems. But stty
is sometimes useful for trouble-shooting.
Two items set by stty are: 1. Hardware flow control by "crtscts" and 2. Ignore the DCD signal from the modem: "clocal". If the modem is not sending a DCD 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 DCD 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 DCD 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 DCD signal) and then exit minicom with no reset so that the DCD signal remains on. Then you may use stty again.