Hardware manual

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 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.
Giving the setserial command
Remember, that 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 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 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*
You'll see some info about how the device driver is configured for your ports. In many cases you'll see some
ports displayed with what appears at first glance to be erroneous IRQs and addresses. But if you also see:
"UART: unknown" just ignore the entire line since no serial port exists at that address.
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 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 already assigned (such as 3e8) it may not
accept it. But if you use 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.
Configuration file
While assignments made by setserial are lost when the PC is powered off, a configuration file may restore
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 setserial runs it uses the info from the configuration file.
Where this configuration file resides depends on your distribution. Look at the start-up scripts somewhere in
the /etc/ tree (such as /etc/init.d/ or /etc/rc.d/) and read the startup script for "serial" or "setserial" or the like. It
Serial HOWTO
Slow baud rates of 1200 or less 43