Hardware manual

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
More info on PCI
PCI ports are not well standardized. Some use main memory for communication with the PC. Some require
special enabling of the IRQ. The output of "lspci -vv" can help determine if one can be supported. If you see a
4-digit IO port, the port might work by just telling "setserial" the IO port and the IRQ. For example, if lspci
shows IRQ 10, I/O at 0xecb8 and you decide to name it ttyS2 then the command is:
setserial /dev/ttyS2 irq 10 port 0xecb8 autoconfig
Note that the boot-time message "Probing PCI hardware" means reading the PnP configuration registers in the
PCI devices which detects info about all PCI cards and on-board PCI devices. This is different than the
probing of IO addresses by the serial driver which means reading certain IO addresses to see if what's read
looks like there's a serial port at that address.
8.4 Common mistakes made re low-level configuring
Here are some common mistakes people make:
setserial command: They run it (without the "autoconfig" and auto_irq options) and think it has
checked the hardware to see if what it shows is correct (it hasn't).
•
setserial messages: They see them displayed on the screen at boot-time (or by giving the setserial
command) and erroneously think that the result always shows how their hardware is actually
configured.
•
/proc/interrupts: When their serial device isn't in use they don't see its interrupt there, and erroneously
conclude that their serial port can't be found (or doesn't have an interrupt set).
•
/proc/ioports and /proc/tty/driver/serial: People think this shows the actual hardware configuration
when it only shows about the same info (possibly erroneous) as setserial.
•
8.5 IRQ & IO Address Must be Correct
There are really two answers to the question "What is my IO and IRQ?" 1. What the device driver thinks has
been set (This is what setserial usually sets and shows.). 2. What is actually set in the hardware. Both 1. and 2.
above should be the same. If they're not it spells trouble since the driver has incorrect info on the physical
serial port. In some cases the hardware is disabled so it has no IO address or IRQ.
If the driver has the wrong IO address it will try to send data to a non-existing serial port --or even worse, to
some other device. If it has the wrong IRQ the driver will not get interrupt service requests from the serial
port, resulting in a very slow or no response. See Extremely Slow: Text appears on the screen slowly after
long delays. If it has the wrong model of UART there is also apt to be trouble. To determine if both IO-IRQ
Serial HOWTO
Introduction 29