mailto:dave@lafn.org
This HOWTO covers conventional analog modems for PCs on the PCI, USB, LPC, and ISA buses. USB and ISDN coverage is weak. For other types of modems see:
For modems on the PCMCIA bus see the PCMCIA-HOWTO: PCMCIA serial and modem devices. This HOWTO also doesn't cover the details of PPP (used to connect to the Internet via a modem) or communication programs. If you want to use a modem to connect to the Internet then you need to use a program that will automatically set up PPP for you (such as wvdial). More documentation on ppp should be found in /usr/doc/ppp, /usr/share/doc/ppp or the like.
Copyright (c) 1998-2005 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:
If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.
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.
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.
"Hayes" is a trademark of Microcomputer Products Inc. I use "winmodem" to mean any modem which originally required MS-Windows and not in the trademark sense. All other trademarks belong to their respective owners.
The following is only a rough approximation of how this this
document was created in the year 2000: About 1/4 of the material here
was lifted directly from Serial-HOWTO v. 1.11 (1997) by Greg Hankins.
mailto:gregh@twoguys.org (with his permission). About
another 1/4 was taken from that Serial-HOWTO and revised. The
remaining 1/2 is newly created by the new author: David S. Lawyer
mailto:dave@lafn.org. Since 2000 much more has
been added by the current author so that little remains of the modem
coverage in the old Serial-HOWTO.
Since I don't follow the many different brands/models of modems please don't email me with questions about them (or suggestions of which one to buy). If you are interested in a certain model (to find out if it works under Linux, etc.) see the huge list at Web Sites. Also, please don't ask me how to configure a modem unless you've looked over this HOWTO and still can't do it. I've no personal experience with software-based modems.
Please let me know of any errors in facts, opinions, logic, spelling, grammar, clarity, links, etc. But first, if the date is over a month or two old, check to see that you have the latest version. Please send me any other info that you think belongs in this document.
New versions of this Modem-HOWTO should come out every few months. Your problem might be solved in the latest version. It will be available to browse and/or download at LDP mirror sites. For a list of such sites see: http://www.tldp.org/mirrors.html If you only want to quickly compare the date of this the version v0.39, January 2007 with the date of the latest version go to: http://www.tldp.org/HOWTO/Modem-HOWTO.html
For a full revision history going back to the first version see the source file (in linuxdoc format) at http://cvsview.tldp.org/index.cgi/LDP/howto/linuxdoc/Modem-HOWTO.sgml.
A modem (or analog modem) is a device that lets one send digital signals over an ordinary telephone line not designed for digital signals. If telephone lines were all digital then you wouldn't need a modem. But sometimes, a substitute for an analog modem, connected to a digital phone line, is imprecisely called a "digital modem". A modem permits your computer to connect to and communicate with the rest of the world. When you use a modem, you normally use a communication program or web browser to utilize the modem and dial-out on a telephone line. Advanced modem users can set things up so that others may phone in to them and use the computer remotely. This is called "dial-in".
Oversimplified, there are four basic types of analog modems for a PC: external serial (RS-232), USB (= external USB), internal, and built-in. The external serial and USB set on your desk outside the PC while the other two types are not visible since they're inside the PC. The external serial modem plugs into a connector on the back of the PC known as a "serial port". The USB modem plugs into a USB cable. See USB Modems. The internal modem is a card that is inserted inside the computer. The built-in modem is a chip on the motherboard used primarily in laptops. What is said in this HOWTO regarding internal modems will generally apply also to built-in modems. Internal modems are further subdivided into PCI, ISA, and AMR, depending on whether they are designed for the PCI or ISA bus, or for an AMR slot.
For an external vs internal comparison see External vs. Internal. When you get an internal or built-in modem, you also get a dedicated serial port (which can only be used with the modem and not with anything else such as an external modem or console terminal). In Linux, the common serial ports are named ttyS0, ttyS1, etc. These ports usually corresponding respectively to COM1, COM2, etc. in Dos/Windows). But in special cases, the names are longer such as: ttySHCF0 is the 0th serial port for a type of winmodem (HCF = Host Controlled Family). New types of serial ports just add some more letters to ttyS.
See Modem & Serial Port Basics for more details on how modems and serial ports work. With a USB modem, the driver simulates a serial port at for example /dev/ttySHCFUSB.
Modems usually include the ability to send Faxes (Fax Modems). See Fax for a list of fax software. "Voice" modems can work like an automatic answering machine and handle voicemail. See Voicemail Software.
The v.92 protocol can put the modem "on hold" when someone makes an ordinary voice call to your telephone, provided that you have "call waiting" from your telephone company. Thus you can get a phone call while online. As of Jan. 2003 Linux doesn't seem to support it. If this is the latest version of this HOWTO, let me know about any Linux support for it. Some linmodem drivers may support it (but what if you have a hardware modem that doesn't use any linmodem driver?).
Internal modems usually have a pair of modular telephone jacks on the back of the computer. They should be right next to each other and each one looks like a jack on the interior wall of a building where a telephone plugs in. One of the pair should be labeled "line" (or the like) which is where you plug in the telephone line.
Network cards also have modular jacks, but they are seldom in pairs and are slightly wider since they normally have 8 pins. Internal DSL "modems" exist and also have modular telephone jacks, but I think they are not very common (most DSL modems are external) as of 2002.
If you think your modem will work under Linux and needs no special driver, then just physically install/connect it. Start you computer, watch the boot-time messages for Linux to find the modem. Note it's the serial port number such as ttyS2 (/dev/ttyS2). Connect a phone line to it and dial out with say wvdial (after configuring wvdial). If the above doesn't work, read on.
So called "winmodems" will work under Linux only if a driver for it exists and gets installed. In this case it's called a "linmodem" since it can be made to work under Linux. If it's made prior to 2004 see old modem list and Software-based Modems (winmodems). There's no point of installing a modem that will not work with Linux.
At one time (2002 ?) no external serial modem was a winmodem but that's no longer the case. With a straight-thru or modem cable, connect the modem to an unused serial port on the PC. Make sure you know the name of the serial port: in most cases COM1 is ttyS0, COM2 is ttyS1, etc. You may need to check the BIOS setup menu to determine this. Plug in the power cord to provide power to the modem. See All Modems for further instructions.
If the modem is both PnP and directly supported by the serial driver (kernel 2.4 +) or by a winmodem driver that you've installed, then there is no configuring for you to do since the driver should configure it.
To physically install a modem card, remove the cover of the PC by /removing some screws. Find a matching vacant slot for the card next to the other adapter cards. Before inserting the card in the slot, remove a small cover plate on the back of the PC so that the telephone jacks on the card will be accessible from the rear of the PC. Then carefully align the card with the slot and push the card all the way down into the slot. Attach the card with a mounting screw (usually 3mm, .5mm pitch --don't use the wrong size).
You may watch the boot-time messages to see if your modem is detected. Use "dmesg" to see them or shift-page-up to scroll the screen back after they have flashed by.
Normally, you don't need to do this manual configuration since the modem's serial port may be detected and assigned a port at boot-time. For example: ttyS14 at I/O 0x6450 (IRQ = 10). Otherwise (or if there is some special reason to change the configuration) then you need to configure it yourself (or perhaps update your kernel to increases the likelihood that the modem gets detected). If your modem has no ttyS number assigned to it, it can't be used until it gets a ttyS number (like ttyS10). It thus can't be detected by application programs such as dialers or minicom. But it might be found by using say "lspci -v" if it's on the PCI bus.
Finding a lost modem may not be easy and you may need to read a lot more of this HOWTO. Once found, you need to use the "setserial" program to manually assign it to an available ttyS? port of your choice . For this you need to know both it's IO address (such as 0x6450) and its IRQ (such as 10). In the worst case, the modem has been disabled by a failing to be detected and enabled by the BIOS (or Linux) and doesn't have any IO address nor IRQ number. But you may still be able to find it. Older modems could be disabled by a jumper on the card or in rare cases by MS software.
You may have some choice of IRQs and IO addresses (including the case where you are able to change what the BIOS has set). See Choosing Serial IRQs and Choosing Addresses.
ISA modems normally use ttyS0 - ttyS3. For old modems with jumpers look at the modem manual or look for printing on the modem card that tells you what the jumpers do. They have standard IO addresses corresponding to the ttySx. For example you may find it feasible to use /dev/ttyS2 at IO address 0x3e8 and IRQ 11.
If it has no jumpers then it's likely a Plug-and-Play modem which the BIOS may configure when you power one your PC. Typing "pnpdump --dumpregs" should find it. If you need to set or change them use "isapnp". Use the "pnpdump" program to see what changes are possible.
You must find the file where "setserial" is run at boot-time and add a line something like: "setserial /dev/ttyS2 irq 5 port 0x0b8". For setserial v2.15 and later the results of running "setserial" on the command line may (or may not) be saved to file named serial.conf or autoserial.conf. It might be in say the /etc directory or in the /var/lib/setserial directory (use "locate to find it). it runs each time you boot. See What is Setserial for more info. See the next subsection All Modems for further instructions on quick installation.
If you are using the BIOS to configure you may attempt to use MS Windows9x to "force" the BIOS to set a certain IRQ and/or IO. It can set them into the PnP BIOS's flash memory where they will be used to configure for Linux as well as Windows. See "Plug-and-Play-HOWTO and search for "forced" (occurs in several places). For Windows3.x you can do the same thing using the ICU under Windows 3.x. A few modems have a way to disable PnP in the modem hardware using software (under Windows) that came with the modem.
Plug the modem into a telephone line. Then configure a dialing program. If you have an Internet Service Provider (ISP) you might configure one of these : wvdial, pppconfig, gnome-ppp, modem lights (Gnome) or kppp. They not only dial out but start PPP, which you need to connect to the Internet. Otherwise, you might try configuring the minicom dialer which isn't designed for connecting to the Internet, but is good for testing. Whether it's minicom or a dialer that starts PPP, set the serial port speed to a baud rate a few times higher than the bit rate of your modem. See Speed Table for more details on the "best" speeds to use. Tell it the full name of your serial port such as /dev/ttyS1 (or /dev/ttys/1).
Minicom is one way to set up and test your modem. Set hardware flow control (RTS/CTS). With minicom you may check to see if your modem is there (and ready to dial). Once you've set up minicom, type the command: AT, hit enter and you should see an "OK" response which comes directly from the modem. See Dialing Out with Minicom.
If your modem is on say /dev/ttyS2, you may want to link that to
/dev/modem. It's not really necessary to do this since you can write
down (or remember) say ttyS2 and tell it to programs that use the
modem. It may be simpler to just link it. To link it, type say
ln -s /dev/ttyS2 /dev/modem . Note "ttyS2" is just for
example. It might actually be ttyS14, etc. Or use Red Hat's
modemtool (or the like) to link it. But once you link it, be sure
that all programs that use the modem use /dev/modem and not
/dev/ttyS2, otherwise two programs may try to use the modem at the
same time without knowing they are doing this. System software was
written around 2000 to fix this problem but it may not be in recent
kernels (like 2.6).
Unfortunately, some software modems (winmodems) will not work with Linux due to lack of Linux drivers. Configuring the software modems that can be made to work with Linux ranges from very easy (automatically) to difficult, depending on both the modem, your skills, and how easy it is to find info about your modem --info that is not all in this HOWTO. If you buy a new one that you're not sure will work under Linux, try to get an agreement that you can return it for a refund if it doesn't work out.
Even if your modem works with Linux it can't be used until the serial port it's located on is enabled and made known to the operating system. For a detailed explanation of this (or if boot-time messages don't show your modem's serial port) study this HOWTO or see Plug-and-Play-HOWTO.
A modem for a PC may be either internal, external serial, or external USB. The internal one is installed inside of your PC (you must remove screws, etc. to install it). An external one just plugs in to a cable: USB cable (USB modem) or to the serial port (RS-232 serial modem). As compared to external serial modems, the internal modems are less expensive, are less likely to to suffer data loss due to buffer overrun, and usually use less electricity. An internal modem obviously doesn't use up any desk space.
External serial modems are usually easier to install and usually has less configuration problems provided the serial port you'll connect it to is configured OK. External USB modems are more likely to be winmodems and are reportedly usually more difficult to deal with than external serial modems. External modems have lights which may give you a clue as to what is happening and aid in troubleshooting. The fact that the serial port and modem can be physically separated also aids in troubleshooting. External modems are easy to move to another computer. If you need to turn the power off to reset your modem (this is seldom necessary) then with an external you don't have to power down the entire PC.
Unfortunately, most external serial modems have no switch to turn off the power supply when not in use and thus are likely to consume a little electricity even when turned off (unless you unplug the power supply from the wall). Each watt they draw usually costs you over $1/yr. Another possible disadvantage of an external is that you will be forced to use an existing serial port which may not support a speed of over 115,200 bps (although as of late 2000 most new internal modems don't either --but some do). For details Can't Set a High Enough Speed
Any modem, of course, needs the serial driver that comes with Linux (either built into the kernel or as a module). For PCI, this driver should also detect the modem but it's not really a modem driver since it just detects which serial port the modem is on.
But what about modem drivers? Any software modem (winmodem, linmodem) must have a modem driver (if it exists for Linux). Hardware modems don't really need any modem driver unless you want to use special features such as voice and "modem on hold".
Software modems require software to run them and obviously do need a driver. The drivers for MS Windows are *.exe programs which will not run under Linux. So you must use a Linux driver (if it exists). See Software-based Modems (winmodems, linmodems)
At one time (2002 ?) all external modems would work under Linux. But then came the controllerless external modem which wouldn't. If the box says it requires Windows with no mention of Linux it could mean just that. Could it be that Windows software is provided for "modem on hold" and for use as an answering machine, etc., but that otherwise it will work under Linux? Linux may not support these features very well if at all. If this is a recent version of Modem-HOWTO, let me know of your experience with this.
Many external modems are labeled "Plug and Play" (PnP). If they are hardware modems, they should all work as non-PnP modems. While the serial port itself may need to be configured (IRQ number and IO address) unless the default configuration is OK, an external modem uses no such IRQ/IO configuration. You just plug the modem into the serial port.
The PnP modem has a special PnP identification built into it that can be read (thru the serial port) by a PnP operating system. Such an operating system would then know that you have a modem on a certain port and would also know the id number. If it's a controllerless modem, it could try to locate a driver for it. It could also tell application programs what port your modem is on (such as /dev/ttyS2 or COM3). But Linux may not be able to do this. Thus you may need to configure your application program manually by giving it the ttyS number (such as /dev/ttyS2). Some programs like wvdial can probe for a modem on various ports.
Connecting an external modem is simple compared to connecting most other devices to a serial port that require various types of "null modem" cables (which will not work for modems). Modems use a straight through cable, with no pins crossed over. Most computer stores should have one. Make sure you get the correct gender and number of pins. Hook up your modem to one of your serial ports. If you are willing to accept the default IRQ and IO address of the port you connect it to, then you are ready to start your communication program and configure the modem itself.
An internal modem is installed in a PC by taking off the cover of the PC and inserting the modem card into a vacant slot on the motherboard. There are modems for PCI slots, other modems for the older ISA slots, and ARM software "modems" for the new small AMR slot. Only some newer PCs will have ARM slots. While external modems plug into the serial port (via a short cable) the internal modems have the serial port built into the modem. In other words, the modem card is both a serial port and a modem.
Setting the IO address and IRQ for a serial port was formerly done by jumpers on the card. These are little black rectangular "cubes" about 5x4x2 mm in size which push in over pins on the card. Plug-and-Play modems (actually the serial port part of the modems) don't use jumpers for setting these but instead are configured by sending configuration commands to them over the bus inside the computer. Such configuration commands can be sent by a PnP BIOS, by the isapnp program (for the ISA bus only), by setpci (PCI bus: can't set IRQs), or by newer serial of how to configure the ones that don't get io-irq configured by the serial driver.
See Quick Install for more details, especially for the PCI bus.
Software modems turn over some (or even almost all) of the work of the modem to the main processor (CPU) chip of your computer (such as a Pentium chip). This requires special software (a modem driver) to do the job. Until late 1999, such software was released only for MS Windows and wouldn't work with Linux. Even worse was that the maker of the modem kept the interface to the modem secret so that no one could write a Linux driver for it (even though a few volunteers were willing to write Linux drivers).
But things have improved some since then so that today (late 2001) many such modems do have a linux driver. There is no standard interface so that different brands/models of software-modems need different drivers (unless the different brands/models happen to use the same chipset internally). But some drivers may not work perfectly nor have all the features that a MS Windows driver has.
Another name for a software modem (used by MS) is "driver-based modem". The conventional hardware-based modem (that works with Linux) doesn't need a modem driver (but does use the Linux serial driver) After about mid-1998 most new internal modems were software modems.
Software modems fall into 2 categories: linmodems and winmodems. Winmodems will only work under MS Windows. Linmodems will work under Linux. They formerly were mostly winmodems so some also call them "winmodems". The term "Winmodem" is also a trademark for a certain model of "winmodem" but that's not the meaning of it in this document.
In late 1999, two software-based modems appeared that could work under Linux and were thus called "linmodems". Lucent Technologies (LT) unofficially released a Linux binary-only code to support most of its PCI modems. PC-TEL (includes "Zoltrix") introduced a new software-based modem for Linux. After that, interest increased for getting winmodems to work under linux. There is a GPL'ed driver for Intel's (Modem Silicon Operations) MD563x HaM chipset (nee Ambient division of Cirrus Logic). As of mid-2001 there are also drivers for: Conexant HSF and HCF, Motorola SM56 (support terminated), ESS (ISA only), and IBM's Mwave for Thinkpads 600+. See http://linmodems.org.
What percent of software modems now (2001) work under Linux? Well, there's a number of modem chips not supported: Lucent/Agere ARM (Scorpio), 3COM/US Robotics, some SmartLink (3 different chipsets), Ambient HSP, and possibly others. So it seems that over half the software modem chips were supported as of late 2001. As of 2005 it seems that the situation has gotten worse. Why? Well, Linux on the Desktop didn't grow as fast as expected and many PC users went for higher speed cable modems and DSL.
Another reason is that many of the drivers were written years ago and will only work for older versions of the Linux kernels. The driver code is secret and the companies don't want to update drivers for hardware they are no longer selling.
Be warned in advance that determining if your modem is a linmodem may not be very easy. You may need to first find out what chipset you have and who makes it. Just knowing the brand and model number of your modem may not be sufficient. One method is to download the scanModem tool from http://linmodems.org but the results may be hard to decipher and you may need to ask for help from the linmodems mailing list. Another way to find this out using say "lspci -v" and then looking up the chip maker using the long modem number. This requires checking a database or searching the Internet. Still another way is to look at the fine print on the chips on the modem card. All this is not always simple. It could happen that you will put a lot of effort into this only to get the bad news that your modem isn't supported. But even if it is supported, support may only be for an old version of the kernel. See Linmodem-HOWTO for more details.
There are two basic types of software modems. In one type the software does almost all of the work. The other is where the software only does the "control" operations (which is everything except processing the digital waveshapes --to be explained later). Since the hardware doesn't do the control it's called a "controllerless" modem. The first type is an all-software modem (sometimes just called a software modem).
For both of these types there must be analog hardware in the modem (or on the motherboard) to generate an electrical waveshape to send out the phone line. It's generated from a digital signal (which is sort of a "digital waveshape"). It's something like the digital electronics creates a lot of discrete points on graph paper and then the modem draws a smooth voltage curve thru them. There must also be hardware to convert the incoming waveshape to digital. This is just analog-to-digital conversion (and conversely). It's done by a codec (coder-decoder).
The incoming digital waveshape must be converted to a data byte stream. This is part of the demodulation process. Recall that these data bytes have likely been compressed, so they are not at all like the original message. Turning data bytes into a digital waveshape is part of the modulation process. Even after demodulation is done, the modem can't just send the resulting incoming data byte stream to the serial port input buffers, but must first do decompression, error correction, and convert from serial to the parallel bus of the computer. But the modem may get the CPU to do the actual work. It's the reverse sequence for an outgoing data byte stream.
The difference between the two types of software-based modems is where the digital modulation takes place. In the all-software modem this modulation is done in the CPU and it's called a Host Signal Processor (HSP). In the controllerless modem it's done in the modem but all other digital work is done by the CPU. This other digital work consists of dealing with AT-commands, data compression, error correction, and simulating a serial port. In the all-software modem, there are still two items handled by hardware: the A/D conversion of waveshapes by the codec and echo cancellation.
How do you determine if an internal modem is a software modem? First see if the name, description of it, or even the name of the MS Windows driver for it indicates it's a software modem: HSP (Host Signal Processor) , HCF (Host Controlled Family), HSF (Host Signal Family), controllerless, host-controlled, host-based, and soft-... modem. If it's one of these modem it will only work for the cases where a Linux driver is available. Since software modems cost less, a low price is a clue that it's a software modem.
If you don't know the model of the modem and you also have Windows on your Linux PC, click on the "Modem" icon in the "Control Panel". Then see the modem list (not maintained after 2003). If the above doesn't work (or isn't feasible), you can look at the package the modem came in (or a manual). Read the section on the package that says something like "Minimum System Requirements" or just "System Requirements".
A hardware modem will work fine on old CPUs (such as the 386 or better). So if it requires a modern CPU (such as a Pentium or other "high speed" CPU of say over 150 MHz) this is a clue that it's a all-software modem. If it only requires a 486 CPU (or better) then it's likely a host-controlled software modem. Saying that it only works with Windows is also bad news. However, even in this case there may be a Linux driver for it or it could be a mistake in labeling.
Otherwise, it may be a hardware modem if it fails to state explicitly that you must have Windows. By saying it's "designed for Windows" it may only mean that it fully supports Microsoft's plug-and-play which is OK since Linux uses the same plug-and-play specs (but it's harder to configure under Linux). Being "designed for Windows" thus gives no clue as to whether or not it will work under Linux. You might check the Website of the manufacturer or inquire via email. Some manufacturers are specifically stating that certain models work under Linux. Sometimes they are linmodems that require you to obtain and install a certain linmodem driver.
Only if you know there is a Linux driver for it that works OK. But there may be a problem if the driver isn't being maintained and as a result doesn't work with future versions of the kernel. Also, the driver may not have full functionality. Besides the problems of getting a satisfactory driver, what are the pros and cons of software modems? Since the software modem uses the CPU to do some (or all) of its work, the software modem requires less on-board electronics on the modem card and thus costs less. At the same time, the CPU work load is increased by the modem which may result in slower operation.
The percentage of loading of the CPU by the modem depends on both what CPU you have and whether or not it's an all-software modem. For a modern CPU and a modem that only uses the CPU as a controller, there's little loss of performance. Even if it's an all-software modem, you will not suffer a loss of performance if there are no other CPU-intensive tasks are running at the same time. Of course, when you're not using the software modem there is no degradation in performance at all.
Is the modem cost savings worth it? In many cases yes, especially if you don't use the modem much and/or are not running any other CPU intensive tasks when the modem is in use. The savings in modem cost could be used for a better CPU which would speed things up a little. But the on-board electronics of a hardware modem can do the job more efficiently than a general purpose CPU (except that it's not efficient at all when it's not in use). So if you use the modem a lot it's probably better to avoid all-software modems.
A PCI modem card is one which inserts into a PCI-bus slot on the motherboard of a PC. While many PCI winmodems will not work under Linux (no driver available) other PCI modems will work under Linux. The Linux serial driver has been modified to support certain PCI hardware modem cards (but not winmodems/linmodems). If it's a linmodem, it will work only if you install a certain linmodem driver. If the Linux serial driver supports your hardware modem then the driver will set up the PnP configuration for you. See PCI Bus Support Underway. If no special support for your PCI hardware modem is in the Linux serial driver it may still work OK but you have to do some work to configure it.
These are mainly used in laptops. They are all winmodems that insert into a special AMR (Audio Modem Riser) slot on the motherboard. Audio cards or combined audio-modem cards are sometimes used in this slot. The slot's main use is for HSF type modems where the CPU does almost all of the work. This results in a small "modem" card and thus a short AMR slot. The motherboard has a codec which takes digital output from the CPU and generates analog voltage waves at the ARM slot (and conversely). Thus the "modem" that plugs into the slot has little to do except to interface the telephone line with the codec. Linux supports at least one AMR modem. lspci -v should display it.
USB = Universal Serial Bus. Most USB modems are winmodems, so many will not work with Linux. Linux has support for modems that conform to the USB Communication Device Class Abstract Control Model (= USB CDC ACM). There's a module for ACM named acm.o. See the /usb/acm.txt document in the kernel documentation directory (/usr/share/doc/kernel-doc-2.6.x in Debian, perhaps /usr/doc/kernel... in some distributions). The ACM "serial port" for the first (0th) such modem is: /dev/usb/acm/0 or possibly /dev/usb/ttyACM0. This should be the case regardless of whether or not you use the new "device file system". It's not really a serial port, but the driver makes it look like a serial port to software which uses the modem.
Since the bandwidth on the USB is high it's possible to send a lot more that just data to a USB modem. This means that it's feasible to create a USB winmodem where the driver does most of the modem's work on the CPU and sends the results to the modem. So beware of USB winmodems (unless they have Linux support).
Note that there's now a Linux driver for the ACP (Mwave) modem used in IBM Thinkpads 600+. See the mini-HOWTO: ACP-Modem.
While hardware modems used use DSPs (Digital Signal Processors) some of these DSPs are programmed by a driver which must be downloaded from the hard disk to the DSPs memory just before using the modem. Unfortunately, such downloading is normally done by Dos/Windows programs (which doesn't work for Linux). But there has been substantial success in getting some of these modems to work with Linux. For example, there is a Linux driver available to run a Lucent (DSP) modem.
Ordinary modems that work fine with Linux (without needing a driver for the modem) often have a DSP too (and may mention this on the packaging), but the program that runs the DSP is stored inside the modem. These work fine under Linux. An example of a DSP modem that has problems working under Linux is the old IBM's Aptiva MWAVE.
One way to get some DSP modems to work with Linux is to boot from DOS (if you have it on your Linux PC). You first install the driver under DOS (using DOS and not Window drivers). Then start Dos/Windows and start the driver for the modem so as to program the DSP. Then without turning off the computer, start Linux.
One may write a "batch" file (actually a script) to do this. Here is an example but you must modify it to suit your situation.
rem mwave is a batch file supplied by the modem maker
call c:\mww\dll\mwave start
rem loadlin.exe is a DOS program that will boot Linux from DOS (See
rem Config-HOWTO).
c:\linux\loadlin f:\vmlinuz root=/dev/hda3 ro
One may create an icon for the Window's desktop which points to such a batch file and set the icon properties to "Run in MSDOS Mode". Then by clicking on this icon one sets up the modem and goes to Linux. Another possible way to boot Linux from DOS is to press CTRL-ALT-DEL and tell it to reboot (assuming that you have set things up so that you can boot directly into Linux). The modem remains on the same com port (same IO address) that it used under DOS.
The Newcom ifx modem needs a small kernel patch to work correctly since its simulation of a serial port is non-standard. The patch and other info for using this modem with Linux is at http://quinine.pharmacy.ohio-state.edu/~ejolson/linux/newcom.html.
Some older Rockwell chips need Rockwell RPI (Rockwell Protocol Interface) drivers for compression and error correction. They can still be used with Linux even though the driver software works only under MS Windows. This is because the MS Windows software (which you don't have) does only compression and error correction. If you are willing to operate the modem without compression and error correction then it's feasible to use it with Linux. To do this you will need to disable RPI by sending the modem (via the initialization string) a "RPI disable" command each time you power on your modem. On my old modem this command was +H0. Not having data compression available makes it slower to get webpages but is just as fast when downloading files that are already compressed.
A "modem pool" is a group of modems which are normally used to receive incoming calls. Today, many such modems may be on a single card. ISPs once used modem pools so that customers could call in to the ISP, but today, the RAS (Remote Access Server) has replaced modem pools for ISPs. RAS works for incoming calls at near 56k (V.90 and V.92) and uses what amounts to "digital modems". Modem pools use the older analog modems and can only go to 33.6 kbps for incoming calls. Thus analog modem pools are more likely to be used by small organizations that don't want to use the more expensive RAS. A RAS is in a sense a digital modem pool.
An analog modem pool may be provided by an analog multi-port modem card. In olden days it was many modems in an external chassis (something like an external modem). Such modems could be analog modems similar to modems used for home/office PCs (can't send above 33.6k even if they are labeled "56k modems"). A RAS will use "digital modems" which can send at nearly 56k (if you have a good line). The "digital modems" require a digital connection to the telephone line and don't use any serial ports at all. All of these modem pools (or RAS's) will require that you install special drivers for them.
A "multimodem card" is short for "multiport modem card". Some put a hyphen after "multi": multi-modem or multi-port. An analog modem pool is just many analog modems (the common home/office modem) provided either on an internal plug-in card or in an external chassis. Each modem comes with a built-in serial port. There is usually a system of sharing interrupts or of handling interrupts by their own electronics, thus removing much of this burden from the CPU. Note that these modems are not "digital modems" and will thus not be able to use 56k for people who dial-in.
Here is a list of some companies that make analog multiport modem cards which plug into slots in a PC. 8 modems/card is common. The cards listed claim to work with Linux and the websites should point you to a driver for them.
Multi-modem Cards (analog, not digital):
"Digital modems" are much different than the analog modems that most people use in their PCs. But they can communicate with analog modems at the other end of the phone line. ISP's use "digital modems" to send out data at almost 56k bps to 56k modems in homes and offices. The "digital modem" requires a digital connection to the telephone line (such as T1, EI, ISDN PRI, etc.). Except for some serial ISDN "modems", they don't use serial ports for the interface to the computer. Instead, they interface directly to a computer bus via a special card(s) (which may also contain the "digital modems"). They are often a component of "remote access servers" (RASs) or "digital modem pools"
You may already know that each time you make a telephone call from an analog device (a telephone or a modem) it gets converted by the telephone company to a digital signal. Then it's transmitted to near its destination as a digital signal and finally converted back into an analog signal just before it reaches it's destination. But it's also possible to receive this digital signal directly from the telephone company if you have what is called a "T1" line, etc.
The cables from the phone company that carry digital signals have been designed for high bandwidth so that the same cable carries many telephone calls. It's done by what's called "time-division multiplexing". A single phone call in a cable is carried on two different channels, one for each direction. So the RAS must connect each such channel-pair to the appropriate "digital modem" that services that phone call. Such tasks are done by what is sometimes called a "... concentrator".
Now the digital signal received by a "digital modem" may really represent an analog signal which has been sent to it by an analog modem. This is because when you send an analog signal (including ordinary voice) to the telephone company, it gets converted into digital by the phone company. One way for the digital modem to deal with this digital signal would be to convert it to an analog signal and then put that thru an analog modem to get the digital data sent by the analog modem. But why do all this work? Since the signal is already in digital form, why not process it digitally? That's how it's done. The digital signal is processed and converted to another digital stream of bytes which represents data bytes sent by the analog modem. A "digital signal processor" (DSP) is commonly used for this task. A CPU could also handle it but it would be heavily loaded.
Likewise, a "digital modem" must handle sending digital signals in the opposite direction from a RAS to a digital telephone line. Thus it only makes digital-to-digital conversions and doesn't deal in analog at all. It thus is not really a modem at all since it doesn't modulate any analog carrier. So the name "digital modem" is a misnomer but it does do the job formerly done by modems. Thus some "digital modems" call themselves "digital signal processors", or "remote access servers", etc. and may not even mention the word "modem".
Such a RAS system may be a stand-alone proprietary server, a chassis containing digital modems that connects to a PC via a special interface card, or just a card itself. Digi calls one such card a "remote access server concentrator adapter". One incomplete description of what is needed to become an ISP is: See What do I need to be an ISP?. Cyclades promotes their own products here so please do comparison shopping before buying anything.
You don't have to understand the basics to use and install a modem. But understanding it may help to determine what is wrong if you run into problems. After reading this section, if you want to understand it even better you may want to see How Modems Work in this document (not yet complete). More details on the serial port (including much of this section) will be found in Serial-HOWTO.
Most all telephone main lines are digital already but the lines leading to your house (or business) are usually analog which means that they were designed to transmit a voltage wave which is an exact replica of the sound wave coming out of your mouth. Such a voltage wave is called "analog". If viewed on an oscilloscope it looks like a sine wave of varying frequency and amplitude. A digital signal is like a square wave. For example 3 v (volts) might be a 1-bit and 0 v could be a 0-bit. For most serial ports (used by external modems) +12 v is a 0-bit and -12 v is a 1-bit (some are + or - 5 v).
To send data from your computer over the phone line, the modem takes the digital signal from your computer and converts it to "analog". It does this by both creating an analog sine wave and then "MODulating" it. Since the result still represents digital data, it could also be called a digital signal instead of analog. But it looks something like an analog signal and almost everyone calls it analog. At the other end of the phone line another modem "DEModulates" this signal and the pure digital signal is recovered. Put together the "mod" and "dem" parts of the two words above and you get "modem" (if you drop one of the two d's). A "modem" is thus a MODulator-DEModulator. Just what modulation is may be found in the section Modulation Details.
The UART serial port (or just "serial port for short" is an I/O (Input/Output) device. Since modems have a serial port between them and the computer, it's necessary to understand the serial port as well as the modem.
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" in the Serial-HOWTO. 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.
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 the Serial-HOWTO: Pinout and Signals for more details.
For an internal modem there is no 9-pin connector but the behavior is almost exactly as if the above mentioned cable wires existed. Instead of a a 12 volt signal in a wire giving the state of a modem control line, the internal modem may just use a status bit in its own memory (a register) to determine the state of this non-existent "wire". The internal modem's serial port looks just like a real serial port to the computer. It even includes the speed limits that one may set at ordinary serial ports such as 115200 bits/sec.
Unfortunately for Linux, many internal modems today use software (running on the CPU) to do much of the modem's work. Unfortunately, such software may be only available for the MS Windows OS (it hasn't been ported to Linux). Thus you can't use some of these modems with Linux See Software-based Modems (winmodems).
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 voltage 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. The PCI bus has its own system of interrupts. But since the PCI-aware BIOS sets up these PCI interrupts to map to IRQs, it seemingly behaves just as described above. Except that sharing of PCI 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 sent on the bus to see if it matches the device's. If the address matches, then the I/O device reads the data on the data bus.
The I/O address of a certain device (such as ttyS2) will actually be a range of addresses. The lower address in this range is the base address. "address" usually means just the "base address".
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.
Bytes come in over the phone line to the modem, are converted from analog to digital by the modem and passed along to the serial port on their way to their destination inside your computer. 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.
For an external modem, there may be no way (such as flow control) to stop the flow rapidly enough to prevent such an overrun. For an internal modem, the 16-byte FIFO buffer is on the same card and most modems will not write to it if it's full. Thus it will not overrun the 16-byte buffers but it may need to use Modem-to-Modem Flow Control to prevent the modem itself from being overrun. This is one advantage of internal modems over an external.
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 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.
Before continuing with the basics of the serial port, one needs to understand about something done by the modem: data compression. In some cases this task is actually done by software run on the computer's CPU but unfortunately at present, such software only works for MS Windows. The discussion here will be for the case where the modem itself does the compression since this is what must happen in order for the modem to work under Linux.
In order to send data faster over the phone line, one may compress (encode it) using a custom encoding scheme which itself depends on the data. The encoded data is smaller than the original (less bytes) and can be sent over the Internet in less time. This process is called "data compression".
If you download files from the Internet, they are likely already compressed and it is not feasible for the modem to try to compress them further. Your modem may sense that what is passing thru has already been compressed and refrain from trying a compress it any more. If you are receiving data which has been compressed by the other modem, your modem will decompress it and create many more bytes than were sent over the phone line. Thus the flow of data from your modem into your computer will be higher than the flow over the phone line to you. The ratio of this flow is called the compression ratio. Compression ratios as high as 4 are possible, but not very likely.
Similar to data compression, modems may be set to do error correction. While there is some overhead cost involved which slows down the byte/sec flow rate, the fact that error correction strips off start and stop bits actually increases the data byte/sec flow rate.
For the serial port's interface with the external world, each 8-bit byte has 2 extra bits added to it: a start-bit and a stop-bit. Without error correction, these extra start and stop bits usually go right thru the modem and out over the phone lines. But when error correction is enabled, these extra bits are stripped off and the 8-bit bytes are put into packets. This is more efficient and results in higher byte/sec flow in spite of the fact that there are a few more bytes added for packet headers and error correction purposes.
Data (bytes representing letters, pictures, etc.) flows from your computer to your modem and then out on the telephone line (and conversely). Flow rates (such as 56k (56000) bits/sec) are (incorrectly) called "speed". But almost everyone says "speed" instead of "flow rate". If there were no data compression the flow rate from the computer to the modem would be about the same as the flow rate over the telephone line.
Actually there are two different speeds to consider at your end of the phone line:
When you dial out and connect to another modem on the other end of the phone line, your modem often sends you a message like "CONNECT 28800" or "CONNECT 115200". What do these mean? Well, its either the DCE speed or the DTE speed. If it's higher than the advertised modem speed it must be the DTE modem-to-computer speed. This is the case for the 115200 speed shown above. The 28800 must be a DCE (modem-to-modem) speed since the serial port has no such speed. One may configure the modem to report either speed. Some modems report both speeds and report the modem-to-modem speed as (for example): CARRIER 28800.
If you have an internal modem you would not expect that there would be any speed limit on the DTE speed from your modem to your computer since you modem is inside your computer and is almost part of your computer. But there usually is since the modem contains a dedicated serial port within it. On some software modems there is no such speed limit.
It's important to understand that the average speed is often less than the specified speed, especially on the short DTE computer-to-modem line. 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 separating the end of one byte and the start of the next byte. In addition, modems will fallback to lower speeds if the telephone line conditions are less than pristine.
For a discussion of what DTE speed is best to use see section What Speed Should I Use.
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.
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 than 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.
If you have set the highest PC-to-modem speed, you may not need flow control in the direction from the modem to a PC. For a complex example of a case where it's needed see "Complex Flow Control Example" in the Serial-HOWTO. To slow down this incoming flow, your modem must tell the other modem to stop sending. See M-M_flow_c name="Modem-to-Modem 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 this 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 data 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 characters, 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. To get software flow control to work for binary data requires both modem (hardware) and software support.
Understanding flow-control theory can be of practical use. For example I used my modem to access the Internet and it seemed to work fine. But after a few months, I tried to send out long files from my PC and a huge amount of retries and errors resulted but it finally succeeded. Receiving in the other direction (from my ISP to me) worked fine. The problem turned out to be a modem with flow control disabled. My modem's buffer was overflowing (overrunning) on long outgoing files since no "stop" signal was ever sent to my computer to halt sending to the modem. There was no problem in the direction from the modem to my computer since the capacity (say 115.2 kbps) of the serial port was always higher than the flow from the telephone line. But it was a problem in the other direction where the PC would send at 115.2 kbps and the modem couldn't handle this high flow resulting in overruns of the modem's buffer. The fix was to enable flow control by putting into the modem's init string an enable-flow-control command.
This is the flow control of the data sent over the telephone lines between two modems. It works as long as error correction is enabled. Actually, even without error correction it's possible to enable software flow control between modems but it may interfere with sending binary data so it's not often used.
It's been mentioned 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 this 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 15 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 sent from the modem) 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 continue to be sent out. Bytes stored in the modem will continue to be sent out the phone line unless the modem has gotten a modem-to-modem flow control stop from the modem at the other end of the phone line.
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 small buffer (in main memory) used to process characters.
Commands to the modem are sent to it from the communication software over the same conductor as used to send data. The commands are short ASCII strings. Examples are "AT&K3" for enabling hardware flow control (RTS/CTS) between your computer and modem; and "ATDT5393401 for Dialing the number 5393401. Note all commands are prefaced by "AT". Some commands such as enabling flow control help configure the modem. Other commands such as dialing a number actually do something. There are about a hundred or so different possible commands. When your communication software starts running, it first sends an "init" string of commands to the modem to configure it. All commands are sent on the ordinary data line before the modem dials (or receives a call).
Once the modem is connected to another modem (on-line mode), everything that is sent from your computer to your modem goes directly to the other modem and is not interpreted by the modem as a command. There is a way to "escape" from this mode of operation and go back to command mode where everything sent to the modem will be interpreted as a command. The computer just sends "+++" with a specified time spacing before and after it. If this time spacing is correct, the modem reverts to command mode. Another way to do this is by a signal on a certain modem control line.
There are a number of lists of modem commands on the Internet. The section Web Sites has links to a couple of such web-sites. Different models and brands of modems do not use exactly the same set of such commands. So what works for one modem might not work for another. Some common commands (not guaranteed to work on all modems) are listed in this HOWTO in the section Modem Configuration
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" in the Serial-HOWTO.
See
What is Setserial for more info on
setserial.
Since each modem has an associated serial port and the port has both hardware and software, there are three parts to configuring a modem:
The above omits a few other things that "setserial" can do besides locating the serial ports. But normally you don't need to use them. Setserial may be used in the future to enable super-high speed.
Communication programs include minicom, seyon, or
wvdial (for PPP) and mgetty for dial-in. Such
communication programs require that you configure them, although the
default configuration they come with may only need a little tweaking.
Unfortunately the communication program doesn't locate the serial port. This "locating" is the low-level PnP configuring of the serial port: setting its IO address and IRQ in both the hardware and the driver. If you are lucky, this will happen automatically when you boot Linux. Setting these in the hardware was formerly done by jumpers and then running "setserial" but today it's done by "Plug-and-Play" software. You may still need "setserial". So if Linux (or the wvdial program, etc.) doesn't report what serial port your modem is on, then you can try to find it yourself per the next section but it may not be easy.
If you need to find a serial port it often helps if you know what bus it's on. If the serial port is on a card, you may know what bus the card inserts into such as a PCI slot. But if the serial port is built into the motherboard it may not be clear what bus it's on. For old motherboards that have ISA bus slots, it's likely on the ISA bus and may not even be Plug-and-Play. But even if all your slots are PCI, the serial port is likely to be on either an ISA bus or LPC bus (also called a "LPC interface"). LPC is common on laptop computers. Type "lspci" to see if it shows "LPC". Unfortunately, the LPC bus has no standard Plug-and-Play method for low-level configuring devices on it. But according to the specs, the BIOS is supposed to do such configuring (using ACPI ??). To see if you have a LPC bus, type "lspci" and look for a LPC bridge or the like.
For a serial port to work properly it first must be given both an IO address and an IRQ. For old hardware (of mid 1990s), jumpers on a card or a saved BIOS setting does it. For newer hardware the BIOS or Linux must set them at boot-time, and the new hardware doesn't remember how it was set once it's powered down. Enabling the hardware (by using software) gives it both an IRQ and an IO address. Without an IO address, it can't be used. Without an IRQ it will need to use inefficient polling methods for which one must set the IRQ to 0 in the serial driver. Using digital signals sent to the hardware by the BIOS or Linux, it all should get configured automatically (provided the BIOS has not been previously set up to disable it). So you only need to read this if you're having problems or if you want to understand how it works.
The driver must of course know both the IO address and IRQ so that it can talk to the serial 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"). A driver may also 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
For the old ISA bus, the driver also probes likely 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 names (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 modern way to do this is for the driver to use PnP methods to detect/set the IO/IRQ and then remember what it did. An easy way for a driver to do this is for the driver to ask the kernel to enable the device and then the kernel tells the driver what IO/IRQ it has used. The old way is using the "setserial" program to tell the driver. 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, an effort is made to detect and configure (low-level) the 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:
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 are 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 port is enabled and the serial driver knows the correct IRQ and IO address, the port will not usually not work at all.
A port may be disabled, either by the BIOS or by failure of Linux to find and enable the port. For modern ports (provided the BIOS hasn't disabled them) manual 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.
IO address, IRQs, etc. 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:
setserial")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.
Although some PCI modems are "winmodems" without a Linux driver (and will not work under Linux), other PCI modems will often work OK under Linux. If it's a software modem, then you need to find a driver for it since support for "winmodems" is not built into their serial driver. See Linmodem-HOWTO.
If you have kernel 2.4 or better, then there should be support for PnP for both the PCI and ISA buses (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). Starting with kernel 2.4, the 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 its 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 tt/ttyS4 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; ./MAKEDEV ttyS4
For the device filesystem, the driver should create the device tts/1
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. Some people have gotten a 3COM 3CP5610 PCI Modem to work that way.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 devices which detects info about all PCI cards and on-board PCI devices 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.
Here are some common mistakes people make:
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.
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.
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 (while holding down shift). It's often tricky to freeze them and you may need to hit Ctrl-Alt-Del while Linux is booting to start rebooting and try again. What these messages display may change as booting progresses and it's often tricky to freeze it at exactly the right words.
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 only
the first of these two messages. Here's an example of the start-up
messages (as of 2004, almost the same as for 1999). Note that in
older versions ttyS1 was displayed in these messages as ttyS01, etc.
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
ttyS0 at 0x03f8 (irq = 4) is a 16550A
ttyS1 at 0x02f8 (irq = 3) is a 16550A
ttyS2 at 0x03e8 (irq = 4) is a 16550A
ttyS4 at port 0xeff0 (irq = 10) is a 16550A
Note that ttyS0-ttyS2 were detected by probing the standard addresses while ttyS4 is a PCI port detected by probing the PCI configuration. Later setserial shows you what was saved in a configuration file (which you may edit), but it's not necessarily correct either:
Loading the saved-state of the serial devices...
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
/dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A
Note that the configuration file only had ttyS1-2 in it so that ttyS0 and ttyS4 were not affected by it. There is also a slight discrepancy: The first message shows ttyS2 at irq=4 while the second shows it at irq=5. In most cases the second message is the correct one. But if you're 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 from a script in the /etc directory tree. 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 the
configuration file is incorrect.
With old jumper-set serial ports Linux sometimes gets IRQs wrong because it doesn't by default probe for IRQs. It just assumes the "standard" ones (first message) or accepts what is in a configuration file (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 ISA 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. You 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) are 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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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 in