Hardware manual

the jumperless serial port is set, setserial is not really needed anymore unless you're having problems or
using old hardware. Furthermore, if the configuration file used by setserial is wrong, then there's trouble.
In this case, if you use setserial to try to find out how the port is configured, it may just repeat the
incorrect information in the configuration file.
setserial can sometimes be of help to find a serial port. But it's only of use if you know the port address
and use the right options. For modern ports, there's usually better ways to look for them by plug-and-play
methods.
Thus the name 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 setserial
tells it, even if it conflicts with what the driver has found by using plug-and-play methods. Too bad that it fails
to at least issue a warning message for such a conflict. 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 setserial is run at boot-time by an initialization
shell script (in the /etc directory tree). But the configuration file which this script uses may be either in the /etc
tree or the /var tree. In some cases, if you want setserial to run at boot-time, you may have to take some
action. setserialwill 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.
While setserial can be made to probe the hardware IO port addresses to try to determine the UART type
and IRQ, this has severe limitations. See Probing. It can't set the IRQ or the port address in the hardware of
PnP or PCI 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 and setserial tells you what the device driver thinks, it might be correct. Or it could be telling you
what 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 Kernel 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 your ports correctly, then there's no
need to use setserial. The driver doesn't probe for the IRQs of old ISA serial ports set with jumpers on
the card and may get these wrong.
Besides the man page for setserial, check out info in /usr/doc/setserial.../ or
/usr/share/doc/setserial. This should tell you how setserial is handled for your distribution of
Linux. While 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.
Serial module unload
If a serial module gets unloaded, the changes previously made by 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.
Slow baud rates of 1200 or less
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
Serial HOWTO
Introduction 42