Many 486 PCs (old) and all Pentiums (or the like) should have modern 16550As (usually called just 16550's) with FIFOs. If you have something really old (pre 1990), the chip may unplug so that you may be able to upgrade by finding a plug-in 16550A chip and replacing your old existing 16450 UART. If the functionality has been built into another type of chip, you are out of luck. If the UART is socketed, then upgrading would be easy if you could find a replacement. The new and old are pin-to-pin compatible. It may be more feasible to just buy a new serial card on the Internet (few retail stores stock them as of 2000) or find a used one.
Modern kernels should not allow the opening of ports with the same IO address. But one may probe for ports even though they are not open. If two ports have the same IO address then old fashioned probing by sending commands to the address will erroneously indicate only one port. But modem device detection at boot-time should discover both ports and report the conflict. In olden days, all sorts of errors were reported/observed for devices illegally attempting to use the same IO address. See Probing.
In the past, to get a certain serial port supported, one might need to modify the C source code, perhaps by adding a #define to it. Today, the use of parameters for modules or the kernel, or the use of configuration options should handle all cases (except possible for antique hardware ??).
For a modem to transmit at nearly 56k requires that it be a special digital modem and have a digital connection to a digital phone line (such as a T1 line). Modems used with serial cards (the modems may either be on the serial card or on another card) normally have no such digital connection so they can't be used at the 56k speed, and thus are obsolete unless one doesn't need to send at 56k. In other words they are obsolete for ISP servers but might be OK for small business or home use.
A partial exception to the above are modem banks that connect to multiport serial cards where the modem bank can access multiplexed digital phone lines. Thus one could use a multiport serial card with a few 56k digital modems for sending at 56k. For both analog and digital modems there is one modem on each serial port so there needs to be an external cable (modem bank to multiport) for each modem. This can lead to a large number of cables. So it's less clutter (and cheaper) to use internal modems without a multiport card. This makes even this "exception" obsolete for high volume work. It's somewhat analogous to the lower cost of an internal modem for a desktop PC as compared to the higher cost (and more cabling) for an external modem. See Modem-HOWTO: Modem Pools, Digital Modems.
The abandoned device-filesystem (devfs) has the /dev directory with subdirectories. As of late 2001, there were problems with lockfiles. For example, the lockfile mechanism considered dev/usb/tts/0 and /dev/tts/0 to be the same device with name "0". Ditto for all other devices that had the same "leaf" name. Also, if some applications use the old name for a device and other applications use the devfs name for the same device, then the lockfiles will have different names. But the serial driver should know they are the same.
Kernel 2.4 introduced the now obsolete optional "device file system" (devfs) with a whole new set of names for everything. Some people used it but the majority probably didn't. But in 2003-4, it was claimed that devfs had unsolvable problems and starting with kernel 2.6.12 it was replaced with "udev" (kernels prior to 2.6.12 also could use udev but with some problems). Although udev doesn't provide all the functionality of devfs, it does handle hot plugging. Also, the use of udev isn't required to run Linux so some people don't use it. But many distributions install it by default.
Devfs was a good idea and was claimed to be more efficient than udev. But unfortunately, the author of devfs didn't maintain it for long and it allegedly became not too well maintained. So for better or worse we now have udev instead although the debate of devfs vs. udev still continues. For a detailed description of devfs see: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html Also see the kernel documentation tree: filesystems/devfs.
The names of devices for the devfs can be used in udev, but usually are not and may not be simple to activate. Here's the devfs names for serial devices: ttyS1 becomes tts/1, ttyUSB1 becomes /usb/tts/1, and ttyACM1 is /usb/acm/1. Note that the number 1 above is just an example. It could be replaced by 0, 2, 3, 4, etc. Some more examples of udev names: ttyS2 becomes tts/2 (Serial port), tty3 becomes vc/3 (Virtual Console), ptyp1 becomes pty/m1 (PTY master), ttyp2 becomes pty/s2 (PTY slave). "tts" looks like a directory which contains devices "files": 0, 1, 2, etc. All of these new names were put in the /dev directory although optionally one may put them elsewhere.
For devfs, device names in the /dev directory are created automatically by the corresponding driver. Thus, if serial support comes from a module and that module isn't loaded yet, there will not be any serial devices in the /dev directory. This can be confusing: you physically have serial ports but don't see them in the /dev directory. However, if a device name is requested (attempt to open it) by a communication program and the serial module isn't loaded, the kernel is supposed to try to find a driver for it and create a name for it in the /dev directory.
This works OK if it finds a driver. But suppose there is no driver found for it. For example, if you try to use "setserial" to configure a port that the driver failed to detect, it claims there is no such port. How does one create a devfs port in this case?
For multiport devices for example, /dev/ttyF9 becomes /dev/ttf/9, or in a later version /dev/tts/F9. Substitute for F (or f) whatever letter(s) your multiport board uses for this purpose. A multiport driver is supposed to create a devfs name similar to the above and put it into the /dev directory
END OF Serial-HOWTO