Welcome to the Linux Serial Driver home page

I have recently switched serial driver development over to SourceForge. The old serial page will be around for a while (and older serial drivers can be downloaded from that site), but new development will be happening here. Check out the Sourceforge summary page. You can submit bugs there, ask questions in the public forums, submit proposed bug fixes, etc.

You can get the latest version of the driver here. This driver has much improved PCI and ISA Plug-and-Play (or is that Plug-and-Pray?) support.

While you're at it, you probably should upgrade your version of setserial to latest release (version 2.17).

Using this serial driver

This serial driver is designed to be used with either a Linux 2.2 or Linux 2.3 kernel, and it can either be compiled as a stand-alone device driver, or you can use the install-in-kernel shell script to install it into a 2.2 or 2.3 kernel tree. (Note: you may need to update some defines in include/linux/pci.h if you take this approach.)

If you are using a stock Red Hat 6.0 or 6.1 kernel, you will need to recompile it to disable the built-in serial driver. Either take it out entirely (CONFIG_SERIAL=N), or compile the built-in serial driver as a module (CONFIG_SERIAL=M). Then build my new serial driver as a stand-alone module, making sure that /usr/src/linux is a symlink to the kernel sources which you are currently running. You can do this by typing the "make" command. The new driver can then be installed using the "make install" command. Warning: depending on how your kernels and modules are set up, this may not work completely correctly.

PCI Modem support

I am getting a lot of e-mail messages about supporting PCI modems, so here's the scoop concerning supporting PCI serial/modem devices. Right now *NO* PCI modems are supported, although support for some are in testing. If you have some PCI modem, please read on below; if you have a PCI serial board which is not a modem, please skip to the next section....

First of all, the serial driver does not, and will never support, controller-less modems, which are somtimes called winmodems. (n.b. Winmodem(tm) is a trademark of 3COM corporation, and refers to a specific brand of controller-less modems. However, people have started using "winmodems", without the capital letter, to refer to the generic class of modems which require a windows specific driver because they do not implement a full modem in hardware.) If you have a PCI-based modem, the odds are about even as to whether or not it is a winmodem or not. The following site, "Winmodems are not modems". Before you send me e-mail, please check your modem against the listing found in the above web site; if it is a winmodem, or controller-less modem, I can't help you.

If your modem isn't listed on the "Winmodems are not modems" web site, there are some other ways you can tell if your PCI modem is a controller-less modem. If the packaging on the box states that Windows 95 or 98 is a requirement, that's a pretty good hint. Modems which are labeled as "HCF" modems (Host Controller Family) from Rockwell are controller-less modems. If you've installed the software on a Windows box, you can check and see how big are the drivers that they've installed. If the driver (typically a .VXD file) is large, that's another tipoff. If the modem is extremely cheap (20 or 30 US dollars), that's another hint. Fundamentally, you get what you pay for.

If you are unfortunate enough to own a winmodem and desire to use it under Linux, there is a project which is trying to develop a driver for some controller-less modem chipsets. But because of the complexities associated with the modem protocol standards (V.90 V.34, and their ilk), they have a long road ahead of them. If you are interested in more information, please refer to the Linmodem Web Site

Getting your PCI serial device supported

So, if you have a PCI device which you're sure is a true, real modem, or if you have a PCI serial board that's not yet supported, what do you need to do? First of all, you need to be familiar with building your own kernel. If not, find a friend who has those skills; unfortunately, I simply don't have the time to walk people through the necessary steps involved; wait, and hopefully someone with those technical skills can work with me through the testing process.

The first step is to obtain the full name of the PCI serial/modem board and the manufacturer. Often the full name of the board is extremely important, so please try to get the whole thing. For example, a proper full model name might be the the US Robotics's "Model 0726, V.90 56K Internal Faxmodem PCI". Don't just tell me that it's a USR V.90 modem; U.S. Robotics has over a dozen different PCI modems, many of which are winmodems, but some of which are not. If you don't have the documentation or the original box for the PCI serial/modem card, power down your system, pull out your board, and take a close look at it. Often the model name will be silkscreened onto the board, or on a sticker which has been pasted on the board somewhere.

The second step is to run the command lspci -v as root. This will result in a listing that contain a large number of entries which look like this:

There will be a large number of such entries, one for each device on your PCI bus. (There will be one entry for each PCI board in your computer, but some PCI devices are built into the motherboard; you won't need to worry about them for the purpose of this exercise.) You will need to find the one which corresponds to your PCI serial/modem board. The entry will either have the manufacturer's name listed, or it may be the one which is listed as "communication controller",as in the above example.

This entry tells us much; it tells us that this PCI serial/modem board uses IRQ 11, and it tells us that the PCI board exports 6 different I/O ports or memory-mapped regions, which this computer has been assigned to the above-listed addresses. Hopefully, there are one or more I/O port regions associated with the card. If you're comfortable using the setserial command, try setting one of your unusued /dev/ttyS devices to one of the I/O port regions listed by lspci, and set its IRQ to the IRQ listed by the lspci listing, and see if you can communicate to your serial port or your modem. I recommend using a low-level modem communications program such as C-Kermit for this testing purpose. If you find that some number of the lspci's I/O regions allow you to talk to the serial port/modem, let me know in your report to me.

If you have a PCI modem which only has memory mapped regions, especially if there is only one memeory mapped region listed by lspci, the odds are very high (although not 100% conclusive) that you have a winmodem. In any case, you will need to contact the manufacturer of your modem for programming information.

Once you have assembled the above information, please mail it to me (tytso@mit.edu). The following bits of information: the full model name of the board, the manufacturer's name, and the lspci -v listing are required if I am to help you. Please don't e-mail me without this information asking for PCI support; I won't have the necessary information to do any good, and you will just be wasting my time. If you were able to do some experimentation with setserial and were able to find out which I/O regions worked for you, please also give me that information.

Periodically, I will release testing serial drivers with my guesses as to how to let the serial driver talk to a particular PCI serial board. As you may have gathered by now, there is no standard PCI serial interface. (The PCI consoritium which is in charge of standardizing the PCI bus must have been asleep at the switch.) This is why your experimentation using setserial is so important; if I don't have your card (and there are so many PCI serial boards out there that the astronomically huge that I won't) I can only guess based on the lspci output the details of how to make the serial driver work with your card. You will need to compile the driver, and try it out. If it works, send me e-mail and let me know about that fact, so I can mark a particular card as being actually supported, since I do keep track of cards which I know work versus cards where I have only guessed at how to make them work.