Return to LinuxDig.Com HowTo's

Serial HOWTO

David S.Lawyer dave@lafn.org original by Greg Hankins

v2.22 December 2003

This document describes the UART serial port features other than those which should be covered by Modem-HOWTO, PPP-HOWTO, Serial-Programming-HOWTO, or Text-Terminal-HOWTO. It lists info on multiport serial cards. It contains technical info about the serial port itself in more detail than found in the above HOWTOs and should be best for troubleshooting when the problem is the serial port itself. If you are dealing with a Modem, PPP (used for Internet access on a phone line), or a Text-Terminal, those HOWTOs should be consulted first.

1. Introduction

2. How the Hardware Transfers Bytes

3. Serial Port Basics

4. Is the Serial Port Obsolete?

5. Multiport Serial Boards/Cards/Adapters

6. Servers for Serial Ports

7. Configuring Overview

8. Locating the Serial Port: IO address, IRQs

9. Configuring the Serial Driver (high-level) "stty"

10. Serial Port Devices /dev/tts/2 = /dev/ttyS2, etc.

11. Interesting Programs You Should Know About

12. Speed (Flow Rate)

13. Locking Out Others

14. Communications Programs And Utilities

15. Serial Tips And Miscellany

16. Troubleshooting

17. Interrupt Problem Details

18. What Are UARTs? How Do They Affect Performance?

19. Pinout and Signals

20. Voltage Waveshapes

21. Other Serial Devices (not async EIA-232)

22. Other Sources of Information

23. Appendix: Obsolete Hardware (prior to 1990) Info

1. Introduction

This HOWTO covers basic info on the Serial Port and multiport serial cards. It contains much more information in it than most people need to know and most people are able to use it without reading this HOWTO. But if you're having problems or just want to understand how it works, this is one place to find out about it.

This HOWTO is about the original serial port which uses a UART chip and is sometimes called a "UART serial port" to differentiate it from the newer Universal Serial Bus. Information specific to modems and text-terminals is found in Modem-HOWTO and Text-Terminal-HOWTO. Info on getty (the program that runs the login process or the like) has been also moved to these HOWTOs since mgetty and uugetty are best for modems while agetty is best for text-terminals. If you are dealing with a modem, text terminal, or printer, then you may not need to consult this HOWTO. But if you are using the serial port for some other device, using a multiport serial card, trouble-shooting the serial port itself, or want to understand more technical details of the serial port, then you may want to use this HOWTO as well as some of the other HOWTOs. (See Related HOWTO's) This HOWTO lists info on various multiport serial cards since they may be used for either modems or text-terminals. This HOWTO addresses Linux running on PCs (ISA or PCI buses), although it might be valid for other architectures.

1.1 Copyright, Disclaimer, & Credits

Copyright

Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2003 by David S. Lawyer mailto:dave@lafn.org

Please freely copy and distribute (sell or give away) this document in any format. Send any corrections and comments to the document maintainer. You may create a derivative work and distribute it provided that you:

  1. If it's not a translation: Email a copy of your derivative work (in a format LDP accepts) to the author(s) and maintainer (could be the same person). If you don't get a response then email the LDP (Linux Documentation Project): submit@en.tldp.org.
  2. License the derivative work in the spirit of this license or use GPL. Include a copyright notice and at least a pointer to the license used.
  3. Give due credit to previous authors and major contributors.

If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.

Disclaimer

While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please let me know about them. Since this is free documentation, it should be obvious that I cannot be held legally responsible for any errors.

Trademarks.

Any brand names (starts with a capital letter such as MS Windows) should be assumed to be a trademark). Such trademarks belong to their respective owners.

Credits

Most of the original Serial-HOWTO was written by Greg Hankins. mailto:gregh@twoguys.org He also rewrote many contributions by others in order to maintain continuity in the writing style and flow. He wrote: ``Thanks to everyone who has contributed or commented, the list of people has gotten too long to list (somewhere over one hundred). Special thanks to Ted Ts'o for answering questions about the serial drivers.'' Approximately half of v2.00 was from Greg Hankins HOWTO and the other half is by David Lawyer. Ted Ts'o has continued to be helpful.

1.2 New Versions of this Serial-HOWTO

New versions of the Serial-HOWTO will be available to browse and/or download at LDP mirror sites. For a list of mirror sites see: 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 http://www.tldp.org/HOWTO/Serial-HOWTO.html and compare it to this version: v2.22 December 2003 .

1.3 New in Recent Versions

For a full revision history going back to the time I started maintaining this HOWTO, see the source file (in linuxdoc format) at http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Serial-HOWTO.sgml.gz.

  • v2.22 Dec. 2003: revised Complex Flow Control Example, more on devfs
  • 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 September 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 stopping data flow when printing, ide2 address conflict

1.4 Related HOWTO's re the Serial Port

Modems, Text-Terminals, some printers, and other peripherals often use the serial port. Get these HOWTOs from the nearest mirror site as explained above.

  • Modem-HOWTO is about installing and configuring modems
  • Printing-HOWTO has info for serial printers using old lpr command
  • LPRng-HOWTO (not a LDP HOWTO, may come with software) has info for serial printing for "Next Generation" lpr
  • Serial-Programming-HOWTO helps you write C programs that read and write to the serial port and/or check/set its state. A version written by Vern Hoxie but not submitted is at Internet.
  • Text-Terminal-HOWTO is about how they work, how to install configure, and repair them. It includes a section on "Make a Terminal the Console" which is useful for using a remote terminal to control a server (via the serial port).
  • Remote-Serial-Console-HOWTO is about making a text-terminal be the console so it can display boot-time messages, etc.

1.5 Feedback

Please send me any suggestions, or additional material. Tell me what you don't understand, or what could be clearer. You can reach me via email at mailto:dave@lafn.org.

1.6 What is a Serial Port?

The conventional serial port (not the newer USB port, or HSSI port) is a very old I/O port. Almost all PC's have them. Macs (Apple Computer) after mid-1998 only have the USB port. However, it's possible, to put a conventional serial port device on the USB.

Each serial port has a "file" associated with it in the /dev directory. It isn't really a file but it seems like one. For newer versions of Linux which use the Device File System (devfs) an ordinary serial port is for example: /dev/tts/0. Formerly (before the devfs) this port was called /dev/ttyS0. Other serial ports are /dev/tts/1, /dev/tts/2, etc. But ports on the USB bus, multiport cards, etc. have different names.

The common specification for the conventional serial port is RS-232 (or EIA-232). The connector for the serial port is often seen as one or two 9-pin connectors (in some cases 25-pin) on the back of a PC. But the serial port is more than just that. It includes the associated electronics which must produce signals conforming to the EIA-232 specification. See Voltage Waveshapes. One pin is used to send out data bytes and another to receive data bytes. Another pin is a common signal ground. The other "useful" pins are used mainly for signalling purposes with a steady negative voltage meaning "off" and a steady positive voltage meaning "on".

The UART (Universal Asynchronous Receiver-Transmitter) chip does most of the work. Today, the functionality of this chip is usually built into another chip. See What Are UARTs? These have improved over time and old models (several years old) are now obsolete.

The serial port was originally designed for connecting modems but it's used to connect many other devices also such as mice, text-terminals, some printers, etc. to a computer. You just plug these devices into the serial port using the correct cable. Many internal modem cards have a built-in serial port so when you install one inside your PC it's as if you just installed another serial port in your PC.

2. How the Hardware Transfers Bytes

Below is an introduction to the topic, but for a more advanced treatment of it see FIFOs.

2.1 Transmitting

Transmitting is sending bytes out of the serial port away from the computer. Once you understand transmitting, receiving is easy to understand since it's similar. The first explanation given here will be grossly oversimplified. Then more detail will be added in later explanations. When the computer wants to send a byte out the serial port (to the external cable) the CPU sends the byte on the bus inside the computer to the I/O address of the serial port. The serial port takes the byte, and sends it out one bit at a time (a serial bit-stream) on the transmit pin of the serial cable connector. For what a bit (and byte) look like electrically see Voltage Waveshapes.

Here's a replay of the above in a little more detail (but still very incomplete). Most of the work at the serial port is done by the UART chip (or the like). To transmit a byte, the serial device driver program (running on the CPU) sends a byte to the serial port"s I/O address. This byte gets into a 1-byte "transmit shift register" in the serial port. From this shift register bits are taken from the byte one-by-one and sent out bit-by-bit on the serial line. Then when the last bit has been sent and the shift register needs another byte to send it could just ask the CPU to send it another byte. Thus would be simple but it would likely introduce delays since the CPU might not be able to get the byte immediately. After all, the CPU is usually doing other things besides just handling the serial port.

A way to eliminate such delays is to arrange things so that the CPU gets the byte before the shift register needs it and stores it in a serial port buffer (in hardware). Then when the shift register has sent out its byte and needs a new byte immediately, the serial port hardware just transfers the next byte from its own buffer to the shift register. No need to call the CPU to fetch a new byte.

The size of this serial port buffer was originally only one byte, but today it is usually 16 bytes (more in higher priced serial ports). Now there is still the problem of keeping this buffer sufficiently supplied with bytes so that when the shift register needs a byte to transmit it will always find one there (unless there are no more bytes to send). This is done by contacting the CPU using an interrupt.

First we'll explain the case of the old fashioned one-byte buffer, since 16-byte buffers work similarly (but are more complex). When the shift register grabs the byte out of the buffer and the buffer needs another byte, it sends an interrupt to the CPU by putting a voltage on a dedicated wire on the computer bus. Unless the CPU is doing something very important, the interrupt forces it to stop what it was doing and start running a program which will supply another byte to the port's buffer. The purpose of this buffer is to keep an extra byte (waiting to be sent) queued in hardware so that there will be no gaps in the transmission of bytes out the serial port cable.

Once the CPU gets the interrupt, it will know who sent the interrupt since there is a dedicated interrupt wire for each serial port (unless interrupts are shared). Then the CPU will start running the serial device driver which checks registers at I/0 addresses to find out what has happened. It finds out that the serial's transmit buffer is empty and waiting for another byte. So if there are more bytes to send, it sends the next byte to the serial port's I/0 address. This next byte should arrive when the previous byte is still in the transmit shift register and is still being transmitted bit-by-bit.

In review, when a byte has been fully transmitted out the transmit wire of the serial port and the shift register is now empty the following 3 things happen almost simultaneously:

  1. The next byte is moved from the transmit buffer into the transmit shift register
  2. The transmission of this new byte (bit-by-bit) begins
  3. Another interrupt is issued to tell the device driver to send yet another byte to the now empty transmit buffer

Thus we say that the serial port is interrupt driven. Each time the serial port issues an interrupt, the CPU sends it another byte. Once a byte has been sent to the transmit buffer by the CPU, then the CPU is free to pursue some other activity until it gets the next interrupt. The serial port transmits bits at a fixed rate which is selected by the user (or an application program). It's sometimes called the baud rate. The serial port also adds extra bits to each byte (start, stop and perhaps parity bits) so there are often 10 bits sent per byte. At a rate (also called speed) of 19,200 bits per second (bps), there are thus 1,920 bytes/sec (and also 1,920 interrupts/sec).

Doing all this is a lot of work for the CPU. This is true for many reasons. First, just sending one 8-bit byte at a time over a 32-bit data bus (or even 64-bit) is not a very efficient use of bus width. Also, there is a lot of overhead in handing each interrupt. When the interrupt is received, the device driver only knows that something caused an interrupt at the serial port but doesn't know that it's because a character has been sent. The device driver has to make various checks to find out what happened. The same interrupt could mean that a character was received, one of the control lines changed state, etc.

A major improvement has been the enlargement of the buffer size of the serial port from 1-byte to 16-bytes. This means that when the CPU gets an interrupt it gives the serial port up to 16 new bytes to transmit. This is fewer interrupts to service but data must still be transferred one byte at a time over a wide bus. The 16-byte buffer is actually a FIFO (First In First Out) queue and is often called a FIFO. See FIFOs for details about the FIFO along with a repeat of some of the above info.

2.2 Receiving

Receiving bytes by a serial port is similar to sending them only it's in the opposite direction. It's also interrupt driven. For the obsolete type of serial port with 1-byte buffers, when a byte is fully received from the external cable it goes into the 1-byte receive buffer. Then the port gives the CPU an interrupt to tell it to pick up that byte so that the serial port will have room for storing the next byte which is currently being received. For newer serial ports with 16-byte buffers, this interrupt (to fetch the bytes) may be sent after 14 bytes are in the receive buffer. The CPU then stops what it was doing, runs the interrupt service routine, and picks up 14 to 16 bytes from the port. For an interrupt sent when the 14th byte has been received, there could be 16 bytes to get if 2 more bytes have arrived since the interrupt. But if 3 more bytes should arrive (instead of 2), then the 16-byte buffer will overrun. It also may pick up less than 14 bytes by setting it that way or due to timeouts. See FIFOs for more details.

2.3 The Large Serial Buffers

We've talked about small 16-byte serial port hardware buffers but there are also much larger buffers in main memory. When the CPU takes some bytes out of the receive buffer of the hardware, it puts them into a much larger (say 8k-byte) receive buffer in main memory. Then a program that is getting bytes from the serial port takes the bytes it's receiving out of that large buffer (using a "read" statement in the program). A similar situation exists for bytes that are to be transmitted. When the CPU needs to fetch some bytes to be transmitted it takes them out of a large (8k-byte) transmit buffer in main memory and puts them into the small 16-byte transmit buffer in the hardware.

3. Serial Port Basics

You don't have to understand the basics to use the serial port But understanding it may help to determine what is wrong if you run into problems. This section not only presents new topics but also repeats some of what was said in the previous section How the Hardware Transfers Bytes but in greater detail.

3.1 What is a Serial Port ?

Intro to Serial

The UART serial port (or just "serial port for short" is an I/O (Input/Output) device.

An I/O device is just a way to get data into and out of a computer. There are many types of I/O devices such as serial ports, parallel ports, disk drive controllers, ethernet boards, universal serial buses, etc. Most PC's have one or two serial ports. Each has a 9-pin connector (sometimes 25-pin) on the back of the computer. Computer programs can send data (bytes) to the transmit pin (output) and receive bytes from the receive pin (input). The other pins are for control purposes and ground.

The serial port is much more than just a connector. It converts the data from parallel to serial and changes the electrical representation of the data. Inside the computer, data bits flow in parallel (using many wires at the same time). Serial flow is a stream of bits over a single wire (such as on the transmit or receive pin of the serial connector). For the serial port to create such a flow, it must convert data from parallel (inside the computer) to serial on the transmit pin (and conversely).

Most of the electronics of the serial port is found in a computer chip (or a part of a chip) known as a UART. For more details on UARTs see the section

What Are UARTS? But you may want to finish this section first so that you will hopefully understand how the UART fits into the overall scheme of things.

Pins and Wires

Old PC's used 25 pin connectors but only about 9 pins were actually used so today most connectors are only 9-pin. Each of the 9 pins usually connects to a wire. Besides the two wires used for transmitting and receiving data, another pin (wire) is signal ground. The voltage on any wire is measured with respect to this ground. Thus the minimum number of wires to use for 2-way transmission of data is 3. Except that it has been known to work with no signal ground wire but with degraded performance and sometimes with errors.

There are still more wires which are for control purposes (signalling) only and not for sending bytes. All of these signals could have been shared on a single wire, but instead, there is a separate dedicated wire for every type of signal. Some (or all) of these control wires are called "modem control lines". Modem control wires are either in the asserted state (on) of +12 volts or in the negated state (off) of -12 volts. One of these wires is to signal the computer to stop sending bytes out the serial port cable. Conversely, another wire signals the device attached to the serial port to stop sending bytes to the computer. If the attached device is a modem, other wires may tell the modem to hang up the telephone line or tell the computer that a connection has been made or that the telephone line is ringing (someone is attempting to call in). See section Pinout and Signals for more details.

RS-232 or EIA-232, etc.

The serial port (not the USB) is usually a RS-232-C, EIA-232-D, or EIA-232-E. These three are almost the same thing. The original RS (Recommended Standard) prefix became EIA (Electronics Industries Association) and later EIA/TIA after EIA merged with TIA (Telecommunications Industries Association). The EIA-232 spec provides also for synchronous (sync) communication but the hardware to support sync is almost always missing on PC's. The RS designation is obsolete but is still widely used. EIA will be used in this howto. Some documents use the full EIA/TIA designation. For info on other (non-EIA-232) serial ports see the section Other Serial Devices (not async EIA-232)

3.2 IO Address & IRQ

Since the computer needs to communicate with each serial port, the operating system must know that each serial port exists and where it is (its I/O address). It also needs to know which wire (IRQ number) the serial port must use to request service from the computer's CPU. It requests service by sending an interrupt on this wire. Thus every serial port device must store in its non-volatile memory both its I/O address and its Interrupt ReQuest number: IRQ. See Interrupts. For the PCI bus it doesn't work exactly this way since the PCI bus has its own system of interrupts. But since the PCI-aware BIOS sets up chips to map these PCI interrupts to IRQs, it seemingly behaves just as described above except that sharing of interrupts is allowed (2 or more devices may use the same IRQ number).

I/O addresses are not the same as memory addresses. When an I/O addresses is put onto the computer's address bus, another wire is energized. This both tells main memory to ignore the address and tells all devices which have I/O addresses (such as the serial port) to listen to the address to see if it matches the device's. If the address matches, then the I/O device reads the data on the data bus.

3.3 Names: ttyS0, ttyS1, etc.

The serial ports are named ttyS0, ttyS1, etc. (and usually correspond respectively to COM1, COM2, etc. in DOS/Windows). The /dev directory has a special file for each port. Type "ls /dev/ttyS*" to see them. Just because there may be (for example) a ttyS3 file, doesn't necessarily mean that there exists a physical serial port there.

Which one of these names (ttyS0, ttyS1, etc.) refers to which physical serial port is determined as follows. The serial driver (software) maintains a table showing which I/O address corresponds to which ttyS. This mapping of names (such as ttyS1) to I/O addresses (and IRQ's) may be both set and viewed by the "setserial" command. See What is Setserial. This does not set the I/O address and IRQ in the hardware itself (which is set by jumpers or by plug-and-play software). Thus which physical port corresponds to say ttyS1 depends both on what the serial driver thinks (per setserial) and what is set in the hardware. If a mistake has been made, the physical port may not correspond to any name (such as ttyS2) and thus it can't be used. See Serial Port Devices /dev/ttyS2, etc. for more details>

3.4 Interrupts

When the serial port receives a number of bytes (may be set to 1, 4, 8, or 14) into its FIFO buffer, it signals the CPU to fetch them by sending an electrical signal known as an interrupt on a certain wire normally used only by that port. Thus the FIFO waits until it has received a number of bytes and then issues an interrupt.

However, this interrupt will also be sent if there is an unexpected delay while waiting for the next byte to arrive (known as a timeout). Thus if the bytes are being received slowly (such as from someone typing on a terminal keyboard) there may be an interrupt issued for every byte received. For some UART chips the rule is like this: If 4 bytes in a row could have been received in an interval of time, but none of these 4 show up, then the port gives up waiting for more bytes and issues an interrupt to fetch the bytes currently in the FIFO. Of course, if the FIFO is empty, no interrupt will be issued.

Each interrupt conductor (inside the computer) has a number (IRQ) and the serial port must know which conductor to use to signal on. For example, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4). A list of them and more will be found in "man setserial" (search for "Configuring Serial Ports"). Interrupts are issued whenever the serial port needs to get the CPU's attention. It's important to do this in a timely manner since the buffer inside the serial port can hold only 16 incoming bytes. If the CPU fails to remove such received bytes promptly, then there will not be any space left for any more incoming bytes and the small buffer may overflow (overrun) resulting in a loss of data bytes.

There is no Flow Control to prevent this.

Interrupts are also issued when the serial port has just sent out all of its bytes from its small transmit FIFO buffer out the external cable. It then has space for 16 more outgoing bytes. The interrupt is to notify the CPU of that fact so that it may put more bytes in the small transmit buffer to be transmitted. Also, when a modem control line changes state, an interrupt is issued.

The buffers mentioned above are all hardware buffers. The serial port also has large buffers in main memory. This will be explained later

Interrupts convey a lot of information but only indirectly. The interrupt itself just tells a chip called the interrupt controller that a certain serial port needs attention. The interrupt controller then signals the CPU. The CPU then runs a special program to service the serial port. That program is called an interrupt service routine (part of the serial driver software). It tries to find out what has happened at the serial port and then deals with the problem such a transferring bytes from (or to) the serial port's hardware buffer. This program can easily find out what has happened since the serial port has registers at IO addresses known to the the serial driver software. These registers contain status information about the serial port. The software reads these registers and by inspecting the contents, finds out what has happened and takes appropriate action.

3.5 Data Flow (Speeds)

Data (bytes representing letters, pictures, etc.) flows into and out of your serial port. Flow rates (such as 56k (56000) bits/sec) are (incorrectly) called "speed". But almost everyone says "speed" instead of "flow rate".

It's important to understand that the average speed is often less than the specified speed. Waits (or idle time) result in a lower average speed. These waits may include long waits of perhaps a second due to Flow Control. At the other extreme there may be very short waits (idle time) of several micro-seconds between bytes. If the device on the serial port (such as a modem) can't accept the full serial port speed, then the average speed must be reduced.

3.6 Flow Control

Flow control means the ability to slow down the flow of bytes in a wire. For serial ports this means the ability to stop and then restart the flow without any loss of bytes. Flow control is needed for modems and other hardware to allow a jump in instantaneous flow rates.

Example of Flow Control

For example, consider the case where you connect a 33.6k external modem via a short cable to your serial port. The modem sends and receives bytes over the phone line at 33.6k bits per second (bps). Assume it's not doing any data compression or error correction. You have set the serial port speed to 115,200 bits/sec (bps), and you are sending data from your computer to the phone line. Then the flow from the your computer to your modem over the short cable is at 115.2k bps. However the flow from your modem out the phone line is only 33.6k bps. Since a faster flow (115.2k) is going into your modem than is coming out of it, the modem is storing the excess flow (115.2k -33.6k = 81.6k bps) in one of its buffers. This buffer would soon overrun (run out of free storage space) unless the high 115.2k flow is stopped.

But now flow control comes to the rescue. When the modem's buffer is almost full, the modem sends a stop signal to the serial port. The serial port passes on the stop signal on to the device driver and the 115.2k bps flow is halted. Then the modem continues to send out data at 33.6k bps drawing on the data it previous accumulated in its buffer. Since nothing is coming into this buffer, the number of bytes in it starts to drop. When almost no bytes are left in the buffer, the modem sends a start signal to the serial port and the 115.2k flow from the computer to the modem resumes. In effect, flow control creates an average flow rate in the short cable (in this case 33.6k) which is significantly less than the "on" flow rate of 115.2k bps. This is "start-stop" flow control.

In the above simple example it was assumed that the modem did no data compression. This could happen when the modem is sending a file which is already compressed and can't be compressed further. Now let's consider the opposite extreme where the modem is compressing the data with a high compression ratio. In such a case the modem might need an input flow rate of say 115.2k bps to provide an output (to the phone line) of 33.6k bps (compressed data). This compression ratio is 3.43 (115.2/33.6). In this case the modem is able to compress the 115.2 bps PC-to-modem flow and send the same data (in compressed form) out the phone line at 33.6bps. There's no need for flow control here so long as the compression ratio remains higher that 3.43. But the compression ratio varies from second to second and if it should drop below 3.43, flow control will be needed

In the above example, the modem was an external modem. But the same situation exists (as of early 2003) for most internal modems. There is still a speed limit on the PC-to-modem speed even though this flow doesn't take place over an external cable. This makes the internal modems compatible with the external modems.

In the above example of flow control, the flow was from the computer to a modem. But there is also flow control which is used for the opposite direction of flow: from a modem (or other device) to a computer. Each direction of flow involves 3 buffers: 1. in the modem 2. in the UART chip (called FIFOs) and 3. in main memory managed by the serial driver. Flow control protects all buffers (except the FIFOs) from overflowing.

Under Linux, the small UART FIFO buffers are not protected by flow control but instead rely on a fast response to the interrupts they issue. Some UART chips can be set to do hardware flow control to protect their FIFOs but Linux (as of early 2003) doesn't seem to support it. FIFO stand for "First In, First Out" which is the way it handles bytes in a queue. All the 3 buffers use the FIFO rule but only the one in the UART is named "FIFO". This is the essence of flow control but there are still some more details.

Symptoms of No Flow Control

Understanding flow-control theory can be of practical use. The symptom of no flow control is that chunks of data missing from files sent without the benefit of flow control. When overflow happens, often hundreds or even thousands of bytes get lost, and all in contiguous chunks.

Hardware vs. Software Flow Control

If feasible, it's best to use "hardware" flow control that uses two dedicated "modem control" wires to send the "stop" and "start" signals. Hardware flow control at the serial port works like this: The two pins, RTS (Request to send) and CTS (Clear to send) are used. When the computer is ready to receive date it asserts RTS by putting a positive voltage on the RTS pin (meaning "Request To Send to me"). When the computer is not able to receive any more bytes, it negates RTS by putting a negative voltage on the pin saying: "stop sending to me". The RTS pin is connected by the serial cable to another pin on the modem, printer, terminal, etc. This other pin's only function is to receive the signal.

For the case of a modem this "other" pin will be the modem's RTS pin. But for a printer, another PC, or a non-modem device, it's usually a CTS pin so a "crossover" or "null modem" cable is required. This cable connects the CTS pin at one end with the RTS pin at the other end (two wires since each end of the cable has a CTS pin). For a modem, a straight-thru cable is used.

For the opposite direction of flow a similar scheme is used. For a modem, the CTS pin is used to send the flow control signal to the CTS pin on the PC. For a non-modem, the RTS pin sends the signal. Thus modems and non-modems have the roles of their RTS and CTS pins interchanged. Some non-modems such as dumb terminals may use other pins for flow control such as the DTR pin instead of RTS.

Software flow control uses the main receive and transmit wires to send the start and stop signals. It uses the ASCII control characters DC1 (start) and DC3 (stop) for this purpose. They are just inserted into the regular stream of data. Software flow control is not only slower in reacting but also does not allow the sending of binary data unless special precautions are taken. Since binary data will likely contain DC1 and DC3, special means must be taken to distinguish between a DC3 that means a flow control stop and a DC3 that is part of the binary code. Likewise for DC1.

3.7 Data Flow Path; Buffers

It's been mention that there are 3 buffers for each direction of flow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pair of larger buffers inside a device connected to the serial port (such as a modem), and a pair of buffers (say 8k) in main memory. When an application program sends bytes to the serial port they first get stashed in the transmit serial port buffer in main memory. The other member of the pair consists of a receive buffer for the opposite direction of byte-flow. Here's an example diagram for the case of browsing the Internet with a browser. Transmit data flow is left to right while receive flow is right to left. There is a separate buffer for each direction of flow. 

application     8k-byte         16-byte        1k-byte        tele-     
BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
program         buffer          buffer         buffer         line

For the transmit case, the serial device driver takes out say 16 bytes from this transmit buffer (in main memory), one byte at a time and puts them into the 16-byte transmit buffer in the serial UART for transmission. Once in that transmit buffer, there is no way to stop them from being transmitted. They are then transmitted to the modem or (other device connected to the serial port) which also has a fair sized (say 1k) buffer. When the device driver (on orders from flow control) stops the flow of outgoing bytes from the computer, what it actually stops is the flow of outgoing bytes from the large transmit buffer in main memory. Even after this has happened and the flow to the modem has stopped, an application program may keep sending bytes to the 8k transmit buffer until it becomes fill. At the same time, the bytes stored in the FIFO and MODEM continue to be sent out until these buffers empty.

When the memory buffer gets fill, the application program can't send any more bytes to it (a "write" statement in a C_program blocks) and the application program temporarily stops running and waits until some buffer space becomes available. Thus a flow control "stop" is ultimately able to stop the program that is sending the bytes. Even though this program stops, the computer does not necessarily stop computing since it may switch to running other processes while it's waiting at a flow control stop.

The above was a little oversimplified in three ways. First, some UARTs can do automatic hardware flow control which can stop the transmission out of the FIFO buffers if needed (not yet supported by Linux). Second, while an application process is waiting to write to the transmit buffer, it could possibly perform other tasks. Third, the serial driver (located between the memory buffer and the FIFO) has it's own buffer (in main memory) used to process characters.

3.8 Complex Flow Control Example

For many situations, there is a transmit path involving several links, each with its own flow control. For example, I type at a text-terminal connected to a PC and the PC (under my control) dials out to another computer using a modem. Today, a "text-terminal" is likely to be just another PC emulating a text-terminal. The main (server) PC, in addition to serving my text-terminal, could also have someone else sitting at it doing something else. Note that calling this PC a "server" is not technically correct but it does serve the terminal.

The text-terminal uses a command-line interface with no graphical display. Every letter I type at the text-terminal goes over the serial cable to my main PC and then over the phone line to the computer that I've dialed out to. To dial out, I've used the communication software: "minicom" which runs on my PC.

This sounds like a simple data path. I hit a key and the byte that key generates flows over just two cables (besides the keyboard cable): 1. the cable from my text-terminal to my PC and 2. the telephone line cable to some other computer. Of course, the telephone cable is actually a number of telephone system cables and includes switches and electronics so that a single physical cable can transmit many phone calls. But I can think of it like one cable (or one link).

Now, let's count the number and type of electronic devices each keystroke-byte has to pass thru. The terminal-to-PC cable has a serial port at each end. The telephone cable has both a serial port and a modem at each end. This adds up to 4 serial ports and 2 modems. Since each serial port has 2 buffers, and each modem one buffer, that adds up to 10 buffers. And that's just for one direction of flow. Each byte also must pass thru the minicom software as well.

While there's just 2 cables in the above scenario, if external modems were used there would be an additional cable between each modem and it's serial port. This makes 4 cables in all. Even with internal modems it's like there is a "virtual cable" between the modem and its serial port. On all these 4 links (or cables), flow control takes place.

Now lets consider an example of the operation of flow control. Consider the flow of bytes from the remote computer at the other end of the phone line to the screen on the text-terminal that I'm sitting at. A real text-terminal has a limit to the speed at which bytes can be displayed on its screen and issues a flow control "stop" from time to time to slow down the flow. This "stop" propagates in a direction opposite to the flow of bytes it controls. What happens when such a "stop" is issued? Let's consider a case where the "stop" waits long enough before canceling it with a "start", so that it gets thru to the remote computer at the other end of the phone line. When it gets there it will stop the program at the remote computer which is sending out the bytes.

Let's trace out the flow of this "stop" (which may be "hardware" on some links and "software" on others). First, suppose I'm "capturing" a long file from the remote computer which is being sent simultaneously to both my text-terminal and a to file on my hard-disk. The bytes are coming in faster than the terminal can handle them so it sends a "stop" out its serial port to a serial port on my PC. The device driver detects it and stops sending bytes from the 8k PC serial buffer (in main memory) to the terminal. But minicom still keeps sending out bytes for the terminal into this 8k buffer.

When this 8k transmit buffer (on the first serial port) is full, minicom must stop writing to it. Minicom stops and waits. But this also causes minicom to stop reading from the 8k receive buffer on the 2nd serial port connected to the modem. Flow from the modem continues until this 8k buffer too fills up and sends a different "stop" to the modem. Now the modem's buffer ceases to send to the serial port and also fills up. The modem (assuming error correction is enabled) sends a "stop signal" to the other modem at the remote computer. This modem stops sending bytes out of its buffer and when its buffer gets fill, another stop signal is sent to the serial port of the remote computer. At the remote computer, the 8-k (or whatever) buffer fills up and the program at the remote computer can't write to it anymore and thus temporarily halts.

Thus a stop signal from a text terminal has halted a program on a remote computer computer. What a long sequence of events! Note that the stop signal passed thru 4 serial ports, 2 modems, and one application program (minicom). Each serial port has 2 buffers (in one direction of flow): the 8k one and the hardware 16-byte one. The application program may have a buffer in its C_code. This adds up to 11 different buffers the data is passing thru. Note that the small serial hardware buffers do not participate directly in flow control. Also note that the two buffers associated with the text-terminal's serial port are going to be dumping their contents to the screen during this flow control halt. This leaves 9 other buffers that may be getting filled up during the flow control halt.

If the terminal speed limitation is the bottleneck in the flow from the remote computer to the terminal, then its flow control "stop" is actually stopping the program that is sending from the remote computer as explained above. But you may ask: How can a "stop" last so long that 9 buffers (some of them large) all get filled up? It seldom happens, but it can actually happen this way if all the buffers were near their upper limits when the terminal sent out the "stop".

But if you were to run a simulation on this you would discover that it's usually more complicated than this. At an instant of time some links are flowing and others are stopped (due to flow control). A "stop" from the terminal seldom propagates back to the remote computer neatly as described above. It may take a few "stops" from the terminal to result in one "stop" at the remote computer, etc. To understand what is going on you really need to observe a simulation which can be done for a simple case with coins on a table. Use only a few buffers and set the upper level for each buffer at only a few coins.

Does one really need to understand all this? Well, understanding this explained to me why capturing text from a remote computer was loosing text. The situation was exactly the above example but modem-to-modem flow control was disabled. Chunks of captured text that were supposed to also get to my hard-disk never got there because of an overflow at my modem buffer due to flow control "stops" from the terminal. Even though the remote computer had a flow path to the hard-disk without bottlenecks, the same flow also went to a terminal which issued flow control "stops" with disastrous results for the branch of the flow going to a file on the hard-disk. The flow to the hard-disk passed thru my modem and since the overflow happened at the modem, bytes intended for the hard-disk were lost.

3.9 Serial Driver Module

The device driver for the serial port is the software that operates the serial port. It is now provided as a serial module. >From kernel 2.2 on, this module will normally get loaded automatically if it's needed. In earlier kernels, you had to have kerneld running in order to do auto-load modules on demand. Otherwise the serial module needed to be explicitly listed in /etc/modules. Before modules became popular with Linux, the serial driver was usually built into the kernel (and sometimes still is). If it's built-in don't let the serial module load or else you will have two serial drivers running at the same time. With 2 drivers there are all sorts of errors including a possible "I/O error" when attempting to open a serial port. Use "lsmod" to see if the module is loaded.

When the serial module is loaded it displays a message on the screen about the existing serial ports (often showing a wrong IRQ). But once the module is used by setserial to tell the device driver the (hopefully) correct IRQ then you should see a second display similar to the first but with the correct IRQ, etc. See Serial Module See What is Setserial for more info on setserial.

4. Is the Serial Port Obsolete?

4.1 Introduction

The answer is yes, but ... The serial port is somewhat obsolete but it's still needed, especially for Linux. The serial port has many shortcomings but almost all new PC's seem to come with them. Linux supports ordinary telephone modems only if they work thru a serial port (although the port may be built into the modem).

The serial port must pass data between the computer and the external cable. Thus it has two interfaces: the serial-port-to cable and the serial-port-to-computer-bus. Both of these interfaces are slow. First we'll consider the interface via external cable to the outside world.

4.2 EIA-232 Cable Is Low Speed & Short Distance

The conventional EIA-232 serial port is inherently low speed and is severely limited in distance. Ads often read "high speed" but it can only work at "high speed" over very short distances such as to a modem located right next to the computer. Compared to a network card, even this "high speed" is actually low speed. All of the EIA-232 serial cable wires use a common ground return wire so that twisted-pair technology (needed for high speeds) can't be used without additional hardware. More modern interfaces for serial ports exist but they are not standard on PC's like the EIA-232 is. See Successors to EIA-232. Some multiport serial cards support them.

It is somewhat tragic that the RS-232 standard from 1969 did not use twisted pair technology which could operate about a hundred times faster. Twisted pairs have been used in telephone cables since the late 1800's. In 1888 (over 110 years ago) the "Cable Conference" reported its support of twisted-pair (for telephone systems) and pointed out its advantages. But over 80 years after this approval by the "Cable Conference", RS-232 failed to utilize it. Since RS-232 was originally designed for connecting a terminal to a low speed modem located nearby, the need for high speed and longer distance transmission was apparently not recognized.

4.3 Inefficient Interface to the Computer

To communicate with the computer, any I/O device needs to have an address so that the computer can write to it and read from it. For this purpose many I/O devices (such as serial ports) use a special type of address known as an I/O addresses (sometimes called an I/O port). The I/O address of a certain device (such as ttys/2) will be a range of addresses. The lower address in this range is the base address. "address" usually means just the "base address".

Instead of using I/O addresses, some I/O devices read and write directly from/to main memory. This provides more bandwidth since the conventional serial I/O system only moves a byte at a time. There are various ways to read/write directly to main memory. One way is called shared memory I/O (where the shared memory is usually on the same card as the I/O device). Other methods are DMA (direct memory access) on the PCI or ISA bus. Strictly speaking, for the PCI bus this is "bus mastering" and not DMA but it's like DMA and a lot faster than true DMA on the old ISA bus.

DMA is a lot faster than the serial-port-to computer-bus interface. Also, the computer bus is capable of 4 (or 8) byte transfers but the serial port only transfers a byte at a time. Interrupts to initiate a series of such single-byte transfers often happen only every 14 bytes.

5. Multiport Serial Boards/Cards/Adapters

5.1 Intro to Multiport Serial

Multiport serial cards install in slots in a PC on the ISA or PCI bus. Instead of being called "... cards" they are also called "... adapters" or "... boards". Each such card provides you with many serial ports. Today they are commonly used for the control of external devices (including automation for both industry and the home). They can connect to computer servers for the purpose of monitoring/controlling the server from a remote location. They were once mainly used for connecting up many dumb terminals and/or modems to serial ports. Today, use of dumb terminals has declined, and several modems (or digital modems) can now be built into an internal card. So multiport serial cards are not as significant as they once were.

Each multiport card has a number of external connecters (DB-25 or RJ45) so that one may connect up a number of devices (modems, terminals, etc.). Each such physical device would then be connected to its own serial port. Since the space on the external-facing part of the card is limited there is often not enough room for all the serial port connectors. To solve this problem, the connectors may be on the ends of cables which come out (externally) from the card (octopus cable). Or they may be on an external box (possibly rack mountable) which is connected by a cable to a multiport card.

5.2 Modem Limitations

For a modem to transmit at nearly 56k requires that it be a special digital modem and have a digital connection to a digital phone line (such as a T1 line). Modem banks that connect to multiport cards do exist, and some have a card that can access multiplexed digital phone lines. Thus one can use a multiport card with a few 56k digital modems.

For both analog and digital modem there is one modem on each serial port so there needs to be an external cable (modem bank to multiport) for each modem. This can lead to a large number of cables. So it's less clutter (and cheaper) to use internal modems without a multiport card. It's somewhat analogous to the lower cost of an internal modem for a desktop PC as compared to the higher cost (and more cabling) for an external modem. See Modem-HOWTO: Modem Pools, Digital Modems.

5.3 Dumb vs. Smart Cards

Dumb multiport cards are not too much different than ordinary serial ports. They are interrupt driven and the CPU of the computer does most all the work servicing them. They usually have a system of sharing a single interrupt for all the ports. This doesn't decrease the load on the CPU since the single interrupt will be sent to the CPU each time any one port needs servicing. Such devices usually require special drivers that you must either compile into the kernel or use as a module. In rare cases thy activate by putting a #define into the source code (or the like).

Smart boards may use ordinary UARTs but handle most interrupts from the UARTs internally within the board. This frees the CPU from the burden of handling all these interrupts. The board may save up bytes in its large internal FIFOs and transfer perhaps 1k bytes at a time to the serial buffer in main memory. It may use the full bus width of 32 bits for making data transfers to main memory (instead of transferring only 8-bit bytes like dumb serial cards do). Not all "smart" boards are equally efficient. Many boards today are Plug-and-Play.

5.4 Getting/Enabling a Driver

Introduction

For a multiport board to work, a special driver for it must be used. This driver may either be built into the kernel source code or supplied as a module. Support for dumb boards is likely to the built into the kernel while smart boards usually need a module.

If you need driver built into the kernel (mostly dumb boards)

A pre-compiled kernel may not have multiport support built in. So you may need to compile it yourself. In kernel 2.4 you should select "CONFIG_SERIAL_EXTENDED" when configuring the kernel (just before you compile). If you select this there will be still more choices presented to you. Even after you do this you may need to edit the resulting source code a little (depending on the card).

If you use a module (mostly for smart boards)

A pre-compiled kernel may come with a pre-compiled module for the board so that you don't need to recompile the kernel. This module must be loaded in order to use it, but the kernel may automatically do this for you if a program is trying to use a device on the smart board (provided there exists a table showing which module to load for the device). This table may be in /etc/modules.conf and/or be internal to the kernel. Also certain parameters may need to be passed to the driver (via lilo's append command or via /etc/modules.conf). For kernel 2.4 the modules should be found in /lib/modules/.../kernel/drivers/char.

Getting info on multiport boards

The board's manufacturer should have info on their website. Unfortunately, info for old boards is sometimes not there but might be found somewhere else on the Internet (including discussion groups). You might also want to look at the kernel documentation in /usr/share/kernel-doc... For configuring the kernel or modules prior to compiling see: Configure.help and search for "serial", etc. There are also kernel documentation files for certain boards including computone, hayes-esp, moxa-smartio, riscom8, specialix, stallion, and sx (specialix).

5.5 Multiport Devices in the /dev Directory,

The serial ports your multiport board uses depends on what kind of board you have. Some have their own device names like /dev/ttyE27 (Stallion) or /dev/ttyD2 (Digiboard), etc. For various other brands, see see devices.txt in the kernel documentation. Some use the standard names like /dev/ttyS14 (/dev/tts/14) and may be found in configuration files that used as arguments to setserial. Such files may be included in a setserial or serial package.

For the device file system (devfs), for example, /dev/ttyF9 becomes /dev/ttf/9, or in a later version /dev/tts/F9. Substitute for F (or f) whatever letter(s) you multiport board uses for this purpose. Your multiport driver is supposed to create a devfs name similar to the above and put it into the /dev directory

5.6 Making Legacy Multiport Devices in the /dev Directory

If you're using the device file system (devfs), then the device driver should create the device name and put it in the /dev directory. Otherwise for a legacy (non-devfs), an installation script may do this for you. But if not, here's some examples of how to create a device name in the /dev directory.

For the legacy names and numbers of other types of serial ports other than ttyS.. See devices.txt in the kernel documentation. Either use the mknod command, or the MAKEDEV script. Typing "man makedev" may show instructions on using it.

Using the MAKEDEV script, you would first become the superuser (root) and type (for example) either: 

linux# MAKEDEV ttyS17

Or if the above doesn't work cd to /dev before giving the above command>. Substitute whatever your port is for ttyS17.

Using mknod is a more complicated option since you need to know the major and minor device numbers. These numbers are in the "devices" file in the kernel documentation. For ttyS serial ports the minor number is: 64 + port number (=81 for the example below). Note the "major" number is always 4 for ttyS devices (and 5 for the obsolete cua devices). So, if you wanted to create a device for ttyS17 using mknod, you would type: 

linux# mknod -m 666 /dev/ttyS17 c 4 81

5.7 Standard PC Serial Cards

In olden days, PCs came with a serial card installed. Later on, the serial function was put on the hard-drive interface card. Today, one or two serial ports are usually built into the motherboard. Most of them (as of 2002) use a 16550 but some use 16650 (32-byte FIFOs). But one may still buy the individual PC serial cards if they need 1-4 more serial ports. These are for tts/0-tts/3 (COM1 - COM4). They can be used to connect external serial devices (modems, serial mice, etc...). Only a tiny percentage of retail computer stores carry such cards. But one can purchase them on the Internet. Before getting a PCI one, make sure Linux supports it.

Here's a list of a few popular brands:

Note: due to address conflicts, you may not be able to use COM4 and IBM8514 video card (or some others) simultaneously. See Avoiding IO Address Conflicts with Certain Video Boards

5.8 Dumb Multiport Serial Boards (with standard UART chips)

They are also called "serial adapters". Each port has its own address. They often have a special method of sharing interrupts which requires that you compile support for them into the kernel.

* => The file that ran setserial in Debian shows some details of configuring
# => See note below for this board

  • AST FourPort and clones (4 ports) * #
  • Accent Async-4 (4 ports) *
  • Arnet Multiport-8 (8 ports)
  • Bell Technologies HUB6 (6 ports)
  • Boca BB-1004 (4 ports), BB-1008 (8 ports), BB-2016 (16 ports; See the Boca mini-howto revised in 2001) * #
  • Boca IOAT66 or? ATIO66 (6 ports, Linux doesn't support its IRQ sharing ?? Uses odd-ball 10-cond RJ45-like connectors)
  • Boca 2by4 (4 serial ports, 2 parallel ports)
  • Byte Runner http://www.byterunner.com
  • Computone ValuePort V4-ISA (AST FourPort compatible) *
  • Digi PC/8 (8 ports) #
  • Dolphin http://www.dolphinfast.com/sersol/
  • Globetek http://www.globetek.com/
  • GTEK BBS-550 (8 ports; See the mini-howto)
  • Hayes ESP (after kernel 2.1.15)
  • HUB-6 See Bell Technologies.
  • Longshine LCS-8880, Longshine LCS-8880+ (AST FourPort compatible) *
  • Moxa C104, Moxa C104+ (AST FourPort compatible) *
  • NI-SERIAL by National Instruments
  • NetBus (2 ports) http://www.netbus.com using patch from http://lists.insecure.org/linux-kernel/2001/Feb/2809.html
  • PC-COMM (4 ports)
  • Sealevel Systems COMM-2 (2 ports), COMM-4 (4 ports) and COMM-8 (8 ports)
  • SIIG I/O Expander 2S IO1812 (4 ports) #
  • STB-4COM (4 ports)
  • Twincom ACI/550
  • Usenet Serial Board II (4 ports) *
  • VScom (uses same driver as ByteRunner)

In general, Linux will support any serial board which uses a 8250, 16450, 16550, 16550A, 16650, etc. UART. See the latest man page for "setserial" for a more complete list.

Notes:

AST Fourport: You might need to specify skip_test in rc.serial.

BB-1004 and BB-1008 do not support DCD and RI lines, and thus are not usable for dialin modems. They will work fine for all other purposes.

Digi PC/8 Interrupt Status Register is at 0x140.

SIIG IO1812 manual for the listing for COM5-COM8 is wrong. They should be COM5=0x250, COM6=0x258, COM7=0x260, and COM8=0x268.

5.9 Intelligent Multiport Serial Boards

Make sure that a Linux-compatible driver is available and read the information that comes with it. These boards use special devices (in the /dev directory), and not the standard tts ones. This information varies depending on your hardware. If you have updated info which should be shown here please email it to me.

Names of Linux driver modules are *.o but these may not work for all models shown. See Modules (mostly for smart boards) The needed module may have been supplied with your Linux distribution. Also, parameters (such as the io and irq often need to be given to the module so you need to find instructions on this (possibly in the source code tree).

There are many different brands, each of which often offers many different cards. No attempt is currently being made to list all the cards here (and many listed are obsolete). But all major brands and websites should be shown here so it something is missing let me know. Go the the webpage shown for more information. These websites often also have info (ads) on related hardware such as modem pools, remote access servers (RASs), and terminal servers. Where there is no webpage, the cards are likely obsolete. If you would like to put together a better list, let me know.

A review of Comtrol, Cyclades, Digi, and Stallion products was printed in the June 1995 issue of the Linux Journal. The article is available at http://www.linuxjournal.com/article.php?sid=1097 name="http://www.ssc.com/lj/issue14">.

Besides the listing of various brands of multiports found above in this HOWTO there is Gary's Encyclopedia - Serial Cards. It's not as complete, but may have some different links.

5.10 Unsupported Multiport Boards

The following boards don't mention any Linux support as of 1 Jan. 2000. Let me know if this changes.

6. Servers for Serial Ports

A computer that has many serial ports (with many serial cables connected to it) is often called a server. Of course, most servers serve other functions besides just serving serial ports, and many do not serve serial ports at all (although they likely have a serial port on them). For example, a "serial server" may have serial cables, each of which runs to a different (non-serial) server. The serial server (perhaps called a "console server") controls, via a console, all the other servers. The console may be physically located remote from the serial server, communicating with the server over a network.

There are two basic types of serial servers. One type is just an ordinary computer (perhaps rack mounted) that uses multiport cards on a PCI bus (or the like). The other type is a proprietary server that is a dedicated computer that serves a special purpose. Servers of both types may be called: serial servers, console servers, print servers, or terminal servers. They are not the same.

The terminal server was originally designed to provide many serial ports, each connected to a dumb text-terminal. Today, a terminal server often connects to graphic terminals over a fast network and doesn't use serial ports since they are too slow. One network cable takes the place of many serial cables and each graphic terminal uses far more bandwidth than the text-terminals did. However, graphic terminals may be run in text mode to reduce the bandwidth required. A more detailed discussion of terminal servers (serial port) is in Text-Terminal-HOWTO. For networked terminal servers (not serial port) see Linux Terminal Server Project (LTSP)

(To-do: Discuss other types of serial servers, but the author knows little about them.)

7. Configuring Overview

Configuring of the serial port should be done automatically, both the serial driver software and by your application software. But sometimes it isn't and you thus need to do it yourself. Or perhaps you need to configure it in a special way, etc. This HOWTO only covers configuration of the serial port itself and not the configuring of any devices attached to the port (such as a modem).

The first part (locating the hardware or low-level configuring) is assigning each port an IO address, IRQ, and name (such as ttyS2). This IO-IRQ pair must be set in both the hardware and told to the serial driver. We might just call this "io-irq" configuring for short. The "setserial" program is sometimes used to tell the driver. PnP methods, jumpers, etc, are used to set the I0 and IRQ in the hardware. Details will be supplied later. If you need to configure but don't understand certain details it's easy to get into trouble. See Locating the Serial Port: IO address IRQs What is Setserial

The second part (high-level configuring) is assigning it a speed (such as 115.2k bits/sec), selecting flow control, etc. This is often done by communication programs such as PPP, minicom, or by getty (which you may run on the port so that others may log into your computer). However you will need to tell these programs what speed you want, etc. by using a menu or a configuration file. This high-level configuring may also be done manually with the stty program. stty is also useful to view the current status if you're having problems. See the section Stty

8. Locating the Serial Port: IO address, IRQs

8.1 IO & IRQ Overview

For a serial port to work properly, it must have both an IRQ and an IO address. Without an IO address, it can't be located and will not work at all. Without an IRQ it will need to use inefficient polling methods for which one must set the IRQ to 0 in the serial driver. So every serial port needs an IO address and IRQ. In olden days this was set by jumpers on a serial port card. Today it's set by digital signals sent to the hardware and this is part of "Plug-and-Play (PnP). It all should get configured automatically so that you only need to read this if you're having problems or if you want to understand how it works.

The driver must also know both the IO address and IRQ so that it can talk to the port chip. Modern serial port drivers (kernel 2.4) try to determine this by PnP methods so one doesn't normally need to tell the driver (by using "setserial"). The modern driver might also enable the serial port and set an IO address or IRQ in the hardware. But unfortunately, there is some PCI serial port hardware that the driver doesn't recognize so you might need to enable the port yourself. See PCI: Enabling a disabled port

The driver also probes likely ISA serial port addresses to see if there are any serial ports there. This works for the case of jumpers and sometimes works for a ISA PnP port when the driver doesn't do ISA PnP (prior to kernel 2.4).

Locating the serial port by giving it an IRQ and IO address is low-level configuring. It's often automatically done by the serial driver but sometimes you have to do it yourself. What follows repeats what was said above but in more detail.

The low-level configuring consists of assigning an IO address, IRQ, and name (such as ttyS2 = tts/2). This IO-IRQ pair must be set in both the hardware and told to the serial driver. And the driver needs to call this pair a name (such as ttyS2). We could call this "io-irq" configuring for short. The "setserial" program is one way to tell the driver. The other way is for the driver to use PnP methods to determine/set the IO/IRQ and then remember what it did. For jumpers there is no PnP but the driver might detect the port if the jumpers are set to the usual I0/IRQ. If you need to configure but don't understand certain details it's easy to get into trouble.

When Linux starts, some effort is made to detect and configure (low-level) serial ports. Exactly what happens depends on your BIOS, hardware, Linux distribution, kernel version, etc. If the serial ports work OK, there may be no need for you to do any more low-level configuring.

If you're having problems with the serial ports, then you may need to do low-level configuring. If you have kernel 2.2 or lower, then you need to do it if you:

  • Plan to use more than 2 ISA serial ports
  • Are installing a new serial port (such as an internal modem)

Starting with kernel 2.2 you may be able to use more that 2 serial ports without doing any low-level configuring by sharing interrupts. All PCI ports should support this but for ISA it only works for some hardware. It may be just as easy to give each port a unique interrupt if they is available. See Interrupt sharing and Kernels 2.2+

The low-level configuring (setting the IRQ and IO address) seems to cause people more trouble than the high-level stuff, although for many it's fully automatic and there is no configuring to be done. Until the serial driver knows the correct IRQ and IO address, the port will not usually not work at all. Also, PnP ports can be disabled so that they don't have any IO address and thus can't be used. However PnP tools such as lspci should be able to find them. Applications, and utilities such as "setserial" and "scanport" (Debian only ??) only probe I0 addresses, don't use PnP tools, and thus can't detect disabled ports.

Even if an ISA port can be found by the probing done by the serial driver it may work extremely slow if the IRQ is wrong. See Extremely Slow: Text appears on the screen slowly after long delays. PCI ports are less likely to get the IRQ wrong.

In the Wintel world, the IO address and IRQ are called "resources" and we are thus configuring certain resources. But there are many other types of "resources" so the term has many other meanings. In summary, the low-level configuring consists of enabling the device, giving it a name (ttyS2 for example) and putting two values (an IRQ number and IO address) into two places:

  1. the device driver (done by PnP or "setserial")
  2. configuration registers of the serial port hardware itself (done by PnP or jumpers)

You may watch the start-up (= boot-time) messages. They are usually correct. But if you're having problems, your serial port may not show up at all or if you do see a message from "setserial" it may not show the true configuration of the hardware (and it is not necessarily supposed to). See I/O Address & IRQ: Boot-time messages.

8.2 PCI Bus Support

Introduction

If you have kernel 2.4, then there should be support for PnP (either built-in or by modules). Some PCI serial ports can be automatically detected and low-level configured by the serial driver. Others may not be.

While kernel 2.2 supported PCI in general, it had no support for PCI serial ports (although some people got them working anyway). The 2.4 serial driver will read the id number digitally stored in the serial hardware to determine how to support it (if it knows how). It should assign an I/O address to it, determine it's IRQ, etc. So you don't need to use "setserial" for it.

There is a possible problem if you don't use the device filesystem. The driver may assign the port to say "ttyS04" per a boot-time message (use dmesg to see it). But if you don't have a "file" dev/ttyS4 then the port will not work. So you will then need to create it, using
cd /dev and then ./MAKEDEV ttyS4
For the device filesystem, the driver should create the device tts/1

More info on PCI

PCI ports are not well standardized. Some use main memory for communication with the PC. Some require special enabling of the IRQ. The output of "lspci -vv" can help determine if one can be supported. If you see a 4-digit IO port, the port might work by just telling "setserial" the IO port and the IRQ. For example, if lspci shows IRQ 10, I/O at 0xecb8 and you decide to name it ttyS2 then the command is:

setserial /dev/ttyS2 irq 10 port 0xecb8 autoconfig

Note that the boot-time message "Probing PCI hardware" means reading the PnP configuration registers in the PCI cards which reveals the IO addresses and IRQs. This is different that the probing of IO addresses by the serial driver which means reading certain IO addresses to see if what's read looks like there's a serial port at that address.

8.3 Common mistakes made re low-level configuring

Here are some common mistakes people make:

  • setserial command: They run it (without the "autoconfig" and auto_irq options) and think it has checked the hardware to see if what it shows is correct (it hasn't).
  • setserial messages: They see them displayed on the screen at boot-time (or by giving the setserial command) and erroneously think that the result always shows how their hardware is actually configured.
  • /proc/interrupts: When their serial device isn't in use they don't see its interrupt there, and erroneously conclude that their serial port can't be found (or doesn't have an interrupt set).
  • /proc/ioports and /proc/tty/driver/serial: People think this shows the actual hardware configuration when it only shows about the same info (possibly erroneous) as setserial.

8.4 IRQ & IO Address Must be Correct

There are really two answers to the question "What is my IO and IRQ?" 1. What the device driver thinks has been set (This is what setserial usually sets and shows.). 2. What is actually set in the hardware. Both 1. and 2. above should be the same. If they're not it spells trouble since the driver has incorrect info on the physical serial port. In some cases the hardware is disabled so it has no IO address or IRQ.

If the driver has the wrong IO address it will try to send data to a non-existing serial port --or even worse, to some other device. If it has the wrong IRQ the driver will not get interrupt service requests from the serial port, resulting in a very slow or no response. See Extremely Slow: Text appears on the screen slowly after long delays. If it has the wrong model of UART there is also apt to be trouble. To determine if both I0-IRQ pairs are identical you must find out how they are set in both the driver and the hardware.

8.5 What is the IO Address and IRQ per the driver ?

Introduction

What the driver thinks is not necessarily how the hardware is actually set. If everything works OK then what the driver thinks is likely correct (set in the hardware) and you don't need to investigate (unless you're curious or want to become a guru). Ways to determine what the driver thinks include: boot-time messages I/O Address & IRQ: Boot-time messages, the /proc directory "files" The /proc directory and setserial, and the "setserial" command.

I/O Address & IRQ: Boot-time messages

In many cases your ports will automatically get low-level configured at boot-time (but not always correctly). To see what is happening, look at the start-up messages on the screen. Don't neglect to check the messages from the BIOS before Linux is loaded (no examples shown here). These BIOS messages may be frozen by pressing the Pause key. Use Shift-PageUp to scroll back to the messages after they have flashed by. Shift-PageDown will scroll in the opposite direction. The dmesg command (or looking at logs in /var/log) will show some of the messages but they seem to miss important ones from setserial. Here's an example of the start-up messages (as of mid 1999). Note that ttyS00 is the same as /dev/ttyS0. 

At first you see what was detected (but the irq is only a wild guess):

Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS02 at 0x03e8 (irq = 4) is a 16550A

Later setserial shows you  what was saved, but it's not necessarily
correct either:

Loading the saved-state of the serial devices...
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
/dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A

Note that there is a slight disagreement: The first message shows ttyS2 at irq=4 while the second shows it at irq=5. dmesg may not display the second message. In most cases the second message is the correct one. But if your having trouble it may be misleading. Before reading the explanation of all of this complexity in the rest of this section, you might just try using your serial port and see if it works OK. If so it may not be essential to read further.

The second message is from the setserial program being run at boot-time. It shows what the device driver thinks is the correct configuration. But this too could be wrong. For example, the irq could actually be set to irq=8 in the hardware (both messages wrong). The irq=5 could be there because someone incorrectly put this into a configuration file (or the like). The fact that Linux sometimes gets IRQs wrong is because it doesn't by default probe for IRQs. It just assumes the "standard" ones (first message) or accepts what you told it when you configured it (second message). Neither of these is necessarily correct. If the serial driver has the wrong IRQ, the serial port is very slow or doesn't seem to work at all.

The first message is a result of Linux probing the serial port addresses but it doesn't probe for IRQs. If a port shows up here it exists but the IRQ may be wrong. Linux doesn't check IRQs because doing so is not foolproof. It just assumes the IRQs are as shown because they are the "standard" values. Your may check them manually with setserial using the autoconfig and auto_irq options but this isn't guaranteed to be correct either.

The data shown by the BIOS messages (which you see at first before Linux is booted) is what is initially set in the hardware. If your serial port is Plug-and-Play (PnP) then it's possible that "isapnp" or "setpci" will run and change these settings. Look for messages about this after Linux starts. The last serial port message shown in the example above should agree with the BIOS messages (as possibly modified by isapnp or setpci). If they don't agree then you either need to change the setting in the port hardware or use setserial to tell the driver what is actually set in the hardware.

Also, if you have Plug-and-Play (PnP) serial ports, they can only be found by PnP software unless the IRQ and IO has been set inside the hardware by Plug-and-Play software. Prior to kernel 2.4 this was a common reason why the start-up messages did not show a serial port that physically exists. A PnP BIOS may automatically low-level configure them. PnP configuring will be explained later.

The /proc directory and setserial

Type "setserial -g /dev/ttyS*". There are some other ways to find this info by looking at "files" in the /proc directory. Be warned that there is no guarantee that the same is set in the hardware.

/proc/ioports will show the IO addresses that the drivers are using. /proc/interrupts shows the IRQs that are used by drivers of currently running processes (that have devices open). It shows how many interrupts have actually be issued. /proc/tty/driver/serial shows much of the above, plus the number of bytes that have been received and sent (even if the device is not now open).

Note that for the IO addresses and IRQ assignments, you are only seeing what the driver thinks and not necessarily what is actually set in the hardware. The data on the actual number of interrupts issued and bytes processed is real however. If you see a large number of interrupts and/or bytes then it probably means that the device is (or was) working. But the interrupts might be from another device. If there are no bytes received (rx:0) but bytes were transmitted (tx:3749 for example), then only one direction of flow is working (or being utilized).

Sometimes a showing of just a few interrupts doesn't mean that the interrupt is actually being physically generated by any serial port. Thus if you see almost no interrupts for a port that you're trying to use, that interrupt might not be set in the hardware. To view /proc/interrupts to check on a program that you're currently running (such as "minicom") you need to keep the program running while you view it.

8.6 What is the IO Address & IRQ of my Serial Port Hardware?

Introduction

If it's PCI or ISA PnP then what's set in the hardware has been done by PnP methods. Even if nothing has been set or the port disabled, PnP ports may still be found by using "lspci -v" or "isapnp --dumpregs". Ports disabled by jumpers (or hardware failures) are completely lost. See ISA PnP ports, PCI: What IOs and IRQs have been set?, PCI: Enabling a disabled port

PnP ports don't store their configuration in the hardware when the power is turned off. This is in contrast to Jumpers (non-PnP) which remain the same with the power off. That's why a PnP port is more likely to be found in a disabled state than an old non-PnP one.

PCI: What IOs and IRQs have been set?

For PCI, the BIOS almost always sets the IRQ and may set the IO address as well. To see how it's set use "lspci -vv" (best) or look in /proc/bus/pci (or for kernels <2.2 /proc/pci). The modem's serial port is often called a "Communication controller". Look for this. If lspci shows "I/O ports at ... [disabled]" then the serial port is disabled and the hardware has no IO address so it's lost and can't be used. See PCI: Enabling a disabled port for how to enable it.

If more than one IO address is shown, the first one is more likely to be it. You can't change the IRQ (at least not with "setpci") This is because if one writes an IRQ it it's hardware register no action is taken on it. It's the BIOS that should actually set up the IRQs and then write the correct value to this register for lspci to view. If you must, change the IO address with "setpci" by changing the BASE_ADDRESS_0 or the like.

PCI: Enabling a disabled port

If the port communicates via an IO address then "lspci -vv" should show "Control: I/O+ ..." with + meaning that the IO address is enabled. If it shows "I/O-" (and "I/O ports at ... [disabled]") then you may need to use the setpci command to enable it. For example "setpci -d 151f:000 command=101". 151f is the vendor id, and 000 is the device id both obtained from "lspci -n -v" or from /proc/bus/pci or from "scanpci -v". The "command=101" means that 101 is put into the command register which is the same as the "Control" register displayed by "lspci". The 101h sets two bits: the 1 sets I/O to + and the 100 part keeps SERR# set to +. In this case only the SERR# bit of the Control register was initially observed to be + when the lspci command was run. So we kept it enabled to + by setting bit 8 (where bit 0 is I/O) to 1 by the first 1 in 101. Some serial cards don't use SERR# so if you see SERR#- then there's no need to enable it so then use: command=1. Then you'll need to set up "setserial" to tell the driver the IO and IRQ.

Bit 8 is actually the 9th bit since we started counting bits from 0. Don't be alarmed that lspci shows a lot of - signs showing that the card doesn't have many features available (or enabled). Serial ports are relatively slow and don't need these features.

Another way to enable it is to let the BIOS do it by telling the BIOS that you don't have a plug-and-play operating system. Then the BIOS should enable it when you start your PC. If you have MS Windows9x on the same PC then doing this might cause problems with Windows (see Plug-and-Play-HOWTO).

ISA PnP ports

For an ISA Plug-and-Play (PnP) port one may try the pnpdump program (part of isapnptools). If you use the --dumpregs option then it should tell you the actual IO address and IRQ set in the port. It should also find an ISA PnP port that is disabled. The address it "trys" is not the device's IO address, but a special address used for communicating with PnP cards.

Finding a port that is not disabled (ISA, PCI, PnP, non-PnP)

Perhaps the BIOS messages will tell you some info before Linux starts booting. Use the shift-PageUp key to step back thru the boot-time messages and look at the very first ones which are from the BIOS. This is how it was before Linux started. Setserial can't change it but isapnp or setpci can. Starting with kernel 2.4, the serial driver can make such changes for many (but not all) serial ports.

Using "scanport" (Debian only ??) will probe all I/O ports and will indicate what it thinks may be serial port. After this you could try probing with setserial using the "autoconfig" option. You'll need to guess the addresses to probe at (using clues from "scanport"). See What is Setserial.

For a port set with jumpers, the IO ports and IRQs are set per the jumpers. If the port is not Plug-and-Play (PnP) but has been setup by using a DOS program, then it's set at whatever the person who ran that program set it to.

Exploring via MS Windows (a last resort)

For PnP ports, checking on how it's configured under DOS/Windows may (or may not) imply how it's under Linux. MS Windows stores its configuration info in its Registry which is not used by Linux so they are not necessarily configured the same. If you let a PnP BIOS automatically do the configuring when you start Linux (and have told the BIOS that you don't have a PnP operating system when starting Linux) then Linux should use whatever configuration is in the BIOS's non-volatile memory. Windows also makes use of the same non-volatile memory but doesn't necessarily configure it that way.

8.7 Choosing Serial IRQs

If you have Plug-and-Play ports then either a PnP BIOS or a serial driver may configure all your devices for you so then you may not need to choose any IRQs. PnP software determines what it thinks is best and assigns them (but it's not always best). But if you directly use isapnp (ISA bus) or jumpers then you have to choose. If you already know what IRQ you want to use you could skip this section except that you may want to know that IRQ 0 has a special use (see the following paragraph).

IRQ 0 is not an IRQ

While IRQ 0 is actually the timer (in hardware) it has a special meaning for setting a serial port with setserial. It tells the driver that there is no interrupt for the port and the driver then will use polling methods. Such polling puts more load on the CPU but can be tried if there is an interrupt conflict or mis-set interrupt. The advantage of assigning IRQ 0 is that you don't need to know what interrupt is set in the hardware. It should be used only as a temporary expedient until you are able to find a real interrupt to use.

Interrupt sharing, Kernels 2.2+

Sharing of IRQs is where two devices use the same IRQ. As a general rule, this wasn't allowed for the ISA bus. The PCI bus may share IRQs but one can't share the same IRQ between the ISA and the PCI bus. Most multi-port boards may share IRQs. Sharing is not as efficient since every time a shared interrupt is given a check must be made to determine where it came from. Thus if it's feasible, it's nicer to allocate every device its own interrupt.

Prior to kernel 2.2, serial IRQs could not be shared with each other except for most multiport boards. Starting with kernel 2.2 serial IRQs may be sometimes shared between serial ports. In order for sharing to work in 2.2 the kernel must have been compiled with CONFIG_SERIAL_SHARE_IRQ, and the serial port hardware must support sharing (so that if two serial cards put different voltages on the same interrupt wire, only the voltage that means "this is an interrupt" will prevail). Since the PCI bus specs permit sharing, any PCI card should allow sharing.

What IRQs to choose?

The serial hardware often has only a limited number of IRQs. Also you don't want IRQ conflicts. So there may not be much of a choice. Your PC may normally come with ttyS0 and ttyS2 at IRQ 4, and ttyS1 and ttyS3 at IRQ 3. Looking at /proc/interrupts will show which IRQs are being used by programs currently running. You likely don't want to use one of these. Before IRQ 5 was used for sound cards, it was often used for a serial port.

Here is how Greg (original author of Serial-HOWTO) set his up in /etc/rc.d/rc.serial. rc.serial is a file (shell script) which runs at start-up (it may have a different name or location). For versions of "setserial" after 2.15 it's not always done this way anymore but this example does show the choice of IRQs. 

/sbin/setserial /dev/ttyS0 irq 3        # my serial mouse
/sbin/setserial /dev/ttyS1 irq 4        # my Wyse dumb terminal
/sbin/setserial /dev/ttyS2 irq 5        # my Zoom modem
/sbin/setserial /dev/ttyS3 irq 9        # my USR modem

Standard IRQ assignments: 

        IRQ  0    Timer channel 0 (May mean "no interrupt".  See below.)
        IRQ  1    Keyboard
        IRQ  2    Cascade for controller 2
        IRQ  3    Serial port 2
        IRQ  4    Serial port 1
        IRQ  5    Parallel port 2, Sound card
        IRQ  6    Floppy diskette
        IRQ  7    Parallel port 1
        IRQ  8    Real-time clock
        IRQ  9    Redirected to IRQ2
        IRQ 10    not assigned
        IRQ 11    not assigned
        IRQ 12    not assigned
        IRQ 13    Math coprocessor
        IRQ 14    Hard disk controller 1
        IRQ 15    Hard disk controller 2

There is really no Right Thing to do when choosing interrupts. Try to find one that isn't being used by the motherboard, or any other boards. 2, 3, 4, 5, 7, 10, 11, 12 or 15 are possible choices. Note that IRQ 2 is the same as IRQ 9. You can call it either 2 or 9, the serial driver is very understanding. If you have a very old serial board it may not be able to use IRQs 8 and above.

Make sure you don't use IRQs 1, 6, 8, 13 or 14! These are used by your motherboard. You will make her very unhappy by taking her IRQs. When you are done you might want to double-check /proc/interrupts when programs that use interrupts are being run and make sure there are no conflicts.

8.8 Choosing Addresses --Video card conflict with ttyS3

Here's a problem with some old serial cards. The IO address of the IBM 8514 video board (and others like it) is allegedly 0x?2e8 where ? is 2, 4, 8, or 9. This may conflict with the IO address of ttyS3 at 0x02e8. Your may think that this shouldn't happen since the addresses are different in the high order digit (the leading 0 in 02e8). You're right, but a poorly designed serial port may ignore the high order digit and respond to any address that ends in 2e8. That is bad news if you try to use ttyS3 (ISA bus) at this IO address.

For the ISA bus you should try to use the default addresses shown below. PCI cards use different addresses so as not to conflict with ISA addresses. The addresses shown below represent the first address of an 8-byte range. For example 3f8 is really the range 3f8-3ff. Each serial device (as well as other types of devices that use IO addresses) needs its own unique address range. There should be no overlaps (conflicts). Here are the default addresses for commonly used serial ports on the ISA bus: 

ttyS0 address 0x3f8
ttyS1 address 0x2f8
ttyS2 address 0x3e8
ttyS3 address 0x2e8

Suppose there is an address conflict (as reported by setserial -g /dev/ttyS*) between a real serial port and another port which does not physically exist (and shows UART: unknown). Such a conflict shouldn't cause problems but it sometimes does in older kernels. To avoid this problem don't permit such address conflicts or delete /dev/ttySx if it doesn't physically exist.

8.9 Set IO Address & IRQ in the hardware (mostly for PnP)

After it's set in the hardware don't forget to insure that it also gets set in the driver by using setserial. For non-PnP serial ports they are either set in hardware by jumpers or by running a DOS program ("jumperless") to set them (it may disable PnP). The rest of this subsection is only for PnP serial ports. Here's a list of the possible methods of configuring PnP serial ports:

  • Using a PnP BIOS CMOS setup menu (usually only for external devices on ttyS0 (Com1) and ttyS1 (Com2))
  • Letting a PnP BIOS automatically configure a PnP serial port See Using a PnP BIOS to I0-IRQ Configure
  • Doing nothing if the serial driver recognized your card OK
  • Using isapnp for a PnP serial port non-PCI)
  • Using setpci (pciutils or pcitools) for the PCI bus

The IO address and IRQ must be set (by PnP) in their registers each time the system is powered on since PnP hardware doesn't remember how it was set when the power is shut off. A simple way to do this is to let a PnP BIOS know that you don't have a PnP OS and the BIOS will automatically do this each time you start. This might cause problems in Windows (which is a PnP OS) if you start Windows with the BIOS thinking that Windows is not a PnP OS. See Plug-and-Play-HOWTO.

Plug-and-Play (PnP) was designed to automate this io-irq configuring, but for Linux it initially made life much more complicated. In modern Linux (2.4 kernels --partially in 2.2 kernels), each device driver has to do it's own PnP (using supplied software which it may utilize). There is unfortunately no centralized planning for assigning IO addresses and IRQs as there is in MS Windows. But it usually works out OK in Linux anyway.

Using a PnP BIOS to I0-IRQ Configure

While the explanation of how to use setpci or isapnp for io-irq configuring should come with such software, this is not the case if you want to let a PnP BIOS do such configuring. Not all PnP BIOS can do this. The BIOS usually has a CMOS menu for setting up the first two serial ports. This menu may be hard to find. For an "Award" BIOS it was found under "chipset features setup" There is often little to choose from. For ISA serial ports, the first two ports normally get set at the standard IO addresses and IRQs. See More on Serial Port Names

Whether you like it or not, when you start up a PC, a PnP BIOS starts to do PnP (io-irq) configuring of hardware devices. It may do the job partially and turn the rest over to a PnP OS (which Linux is in some sense) or if thinks you don't have a PnP OS it may fully configure all the PnP devices but not configure the device drivers.

If you tell the BIOS that you don't have a PnP OS, then the PnP BIOS should do the configuring of all PnP serial ports --not just the first two. An indirect way to control what the BIOS does (if you have Windows 9x on the same PC) is to "force" a configuration under Windows. See Plug-and-Play-HOWTO and search for "forced". It's easier to use the CMOS BIOS menu which may override what you "forced" under Windows. There could be a BIOS option that can set or disable this "override" capability.

If you add a new PnP device, the BIOS should PnP configure it. It could even change the io-irq of existing devices if required to avoid any conflicts. For this purpose, it keeps a list of non-PnP devices provided that you have told the BIOS how these non-PnP devices are io-irq configured. One way to tell the BIOS this is by running a program called ICU under DOS/Windows.

But how do you find out what the BIOS has done so that you set up the device drivers with this info? The BIOS itself may provide some info, either in its setup menus of via messages on the screen when you turn on your computer. See What is set in my serial port hardware?. Other ways of finding out is to use lspci for the PCI bus or isapnp --dumpregs for the ISA bus. The cryptic results it shows you may not be clear to a novice.

8.10 Giving the IRQ and IO Address to Setserial

Once you've set the IRQ and IO address in the hardware (or arranged for it to be done by PnP) you also need to insure that the "setserial" command is run each time you start Linux. See the subsection Boot-time Configuration

9. Configuring the Serial Driver (high-level) "stty"

9.1 Overview

See the section Stty. The "stty" command sets many things such as flow control, speed, and parity. The only one discussed in this section is flow control.

9.2 Flow Control

Configuring Flow Control: Hardware Flow Control is Usually Best See Flow Control for an explanation of it. It's usually better to use hardware flow control rather than software flow control using Xon/Xoff. To use full hardware flow control you must normally have two wires for it in the cable between the serial port and the device. If the device is on a card or the motherboard, then it should always be possible to use hardware flow control.

Many applications (and the getty program) give you an option regarding flow control and will set it for you. It might even set hardware flow control by default. It must be set both in the serial driver and in the hardware connected to the serial port. How it's set into the hardware is hardware dependent. Sometimes there is a certain "init string" you send to the hardware device via the serial port from your PC. For a modem, the communication program should set it in both places.

If a program you use doesn't set flow control in the serial driver, then you may do it yourself using the stty command. Since the driver doesn't remember the setting after you stop Linux, you could put the stty command in a file that runs at start-up or when you login (such as /etc/profile for the bash shell). Here's what you would add for hardware flow control for port ttyS2: 

stty crtscts < /dev/ttyS2
or for stty version >= 1.17:
stty -F /dev/ttyS2 crtscts

crtscts stands for a Control setting to use the RTS and CTS pins of the serial port for hardware flow control. Note that RTS+CTS almost spells: crtscts.

10. Serial Port Devices /dev/tts/2 = /dev/ttyS2, etc.

10.1 Serial Port Names: ttyS2, tts/1, etc.

Once upon a time the names of the serial ports were simple. Except for some multiport serial cards they were named /dev/ttyS0, /dev/ttyS1, etc. Then around the year 2000 came the USB bus with names like /dev/ttyUSB0 and /dev/ttyACM1 (for the ACM modem on the USB bus). A little later with kernel 2.4 came the "device file system" (devfs) with a whole new set of names for everything. ttyS1 is now tts/1, ttyUSB1 is now /usb/tts/1, and ttyACM1 is now /usb/acm/1. Note that the the number 1 above is just an example. It could be replaced by 0, 2, 3, etc. The use of the device file system is optional and many are still using the legacy system. Others use devfs but have the old legacy names linked (via symlinks) to the new names. So they use the new system with the old names but may also use some of the new names for some devices. It's even possible ?? to use the new names for the old (non-devfs) system.

10.2 Devfs (The Device File System)

Starting with kernel 2.4, a new system of device naming was created. It makes it easy to deal with a huge number of devices. But there's an option to continue using the old names. However, a new device may not have an old-style name so then one must use the new devfs. For a detailed description of it see: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html Also see the kernel documentation tree: filesystems/devfs.

Some more examples of name changes are: ttyS2 becomes tts/2 (Serial port), tty3 becomes vc/3 (Virtual Console), ptyp1 becomes pty/m1 (PTY master), ttyp2 becomes pty/s2 (PTY slave). "tts" looks like a directory which contains devices "files": 0, 1, 2, etc. All of these new names should still be in the /dev directory although optionally one may put them elsewhere.

Device names in the /dev directory are created automatically by the corresponding driver. Thus, if serial support comes from a module and that module isn't loaded yet, there will not be any serial devices in the /dev directory. This can be confusing: you physically have serial ports but don't see them in the /dev directory. However, if a device name is told to a communication program and the serial module isn't loaded, the kernel is supposed to try to find a driver for it and create a name for it in the /dev directory.

This is works OK if it finds a driver. But suppose there is no driver found for it. For example, if you try to use "setserial" to configure a port that the driver failed to detect, it claims there is no such port. How does one create a devfs port in this case?

10.3 Legacy Serial Port Device Names & Numbers

Before the device file system, devices in Linux had major and minor numbers. The serial port ttySx (x=0,1,2, etc.) was major number 4. You could see this (and the minor numbers too) by typing: "ls -l ttyS*" in the /dev directory. To find the old device names for various devices, see the "devices" file in the kernel documentation.

There formerly was a "cua" name for each serial port and it behaved just a little differently. For example, ttyS2 would correspond to cua2. It was mainly used for modems. The cua major number was 5 and minor numbers started at 64. You may still have the cua devices in your /dev directory but they are now deprecated. For details see Modem-HOWTO, section: cua Device Obsolete.

For creating the old devices in the device directory see:

Creating Devices In the /dev directory

10.4 More on Serial Port Names

Dos/Windows use the COM name while the messages from the serial driver use ttyS00, ttyS01, etc. Older serial drivers (2001 ?) used just tty00, tty01, etc.

The tables below shows some examples of serial device names. The IO addresses are the default addresses for the old ISA bus (not for the newer PCI and USB buses). The major/minor numbers aren't needed for the devfs, but they often exist anyway just in case the devfs method of locating drivers can't be used. 

                             old   old  ISA IO
 dos     devfs     old name major minor address 
COM1  /dev/tts/0  /dev/ttyS0  4,  64;   3F8
COM2  /dev/tts/1  /dev/ttyS1  4,  65;   2F8
COM3  /dev/tts/2  /dev/ttyS2  4,  66;   3E8
COM4  /dev/tts/3  /dev/ttyS3  4,  67;   2E8

     DEVICES-ON-THE-USB-BUS (acm is a certain type of modem)
     devfs       legacy name           devfs      legacy name
/dev/usb/tts/0  /dev/ttyUSB0  |  /dev/usb/acm/0  /dev/ttyACM0
/dev/usb/tts/1  /dev/ttyUSB1  |  /dev/usb/acm/1  /dev/ttyACM1
/dev/usb/tts/2  /dev/ttyUSB2  |  /dev/usb/acm/2  /dev/ttyACM2
/dev/usb/tts/3  /dev/ttyUSB3  |  /dev/usb/acm/3  /dev/ttyACM3

10.5 USB (Universal Serial Bus) Serial Ports

For more info see the usb subdirectory in the kernel documentation directory for files: usb-serial, acm, etc.

10.6 Link ttySN to /dev/modem

On some installations, two extra devices will be created, /dev/modem for your modem and /dev/mouse for a mouse. Both of these are symbolic links to the appropriate serial device in /dev which you specified during the installation Except if you have a bus mouse, then /dev/mouse will point to the bus mouse device).

Historical note: Formerly (in the 1990s) the use of /dev/modem was discouraged since lock files might not realize that it was really say /dev/ttyS2. The newer lock file system doesn't fall into this trap so it's now OK to use such links.

10.7 Which Connector on the Back of my PC is ttyS1, etc?

Inspect the connectors

Inspecting the connectors may give some clues but is often not definitive. The serial connectors on the back side of a PC are usually DB connectors with male pins. 9-pin is the most common but some are 25-pin (especially older PCs like 486s). There may be one 9-pin (perhaps ttyS0 ??) and one 25-pin (perhaps ttyS1 ??). For two 9-pin ones the top one might be ttyS0.

If you only have one serial port connector on the back of your PC, this may be easy. If you also have an internal modem, a program like wvdial may be able to tell you what port it's on (unless it's a PnP that hasn't been enabled yet). A report from setserial (at boot-time or run by you from the command line) should help you identify the non-modem port.

If you have two serial connectors it may be more difficult. First check manuals (if any) for your computer. Look at the connectors for meaningful labels. You might even want to take off the PC's cover and see if there are any meaningful labels on the card where the internal ribbon cables plug in. Labels (if any) are likely to say something like "serial 1", "serial 2" or A, B. Which com port it actually is will depend on jumper or PnP settings (sometimes shown in a CMOS setup menu). But 1 or A are more likely to be ttyS0 with 2 or B ttyS1.

Send bytes to the port

Labels are not apt to be definitive so here's another method. If the serial ports have been configured correctly per setserial, then you may send some bytes out a port and try to detect which connector (if any) it's coming out of. One way to send such a signal is to copy a long text file to the port using a command like: cp my_file_name /dev/ttyS1. A voltmete