Hardware manual

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.
The /proc directory and setserial
Type "setserial -g /dev/ttyS*". There are some other ways to find this info by looking at "files" in the /proc
directory. Be warned that there is no guarantee that the same is set in the hardware.
/proc/ioports will show the IO addresses that the drivers are using. /proc/interrupts shows the
IRQs that are used by drivers of currently running processes (that have devices open). It shows how many
interrupts have actually be issued. /proc/tty/driver/serial shows much of the above, plus the
number of bytes that have been received and sent (even if the device is not now open).
Note that for the IO addresses and IRQ assignments, you are only seeing what the driver thinks and not
necessarily what is actually set in the hardware. The data on the actual number of interrupts issued and bytes
processed is real however. If you see a large number of interrupts and/or bytes then it probably means that the
device is (or was) working. But the interrupts might be from another device. If there are no bytes received
(rx:0) but bytes were transmitted (tx:3749 for example), then only one direction of flow is working (or being
utilized).
Sometimes a showing of just a few interrupts doesn't mean that the interrupt is actually being physically
generated by any serial port. Thus if you see almost no interrupts for a port that you're trying to use, that
interrupt might not be set in the hardware. To view /proc/interrupts to check on a program that you're
currently running (such as "minicom") you need to keep the program running while you view it.
Serial HOWTO
I/O Address & IRQ: Boot-time messages 31