While the section Troubleshooting lists problems by symptom, this section explains what will happen if something is set incorrectly. This section helps you understand what caused the symptom and what other symptoms might be due to the same problem.
If you don't understand what an interrupt does see Interrupts. If a serial port has one IRQ set in the hardware but a different one set in the device driver, the device driver will not receive any interrupts sent by the serial port. Since the serial port uses interrupts to tell its driver when it needs service (fetching bytes from it's 16-byte receive buffer or putting another 16-bytes in its transmit buffer) one might expect that the serial port would not work at all.
But it still may work anyway --sort of. Why? Well, besides the interrupt method of servicing the port there's a polling method that doesn't need interrupts. The way it works is that every so often the device driver checks the serial port to see if it needs anything such as if it has some bytes that need fetching from its receive buffer. If interrupts don't work, the serial driver falls back to this polling method. But this polling method was not intended to be used a substitute for interrupts. It's so slow that it's not practical to use and may cause buffer overruns. Its purpose may have been to get things going again if just one interrupt is lost or fails to do the right thing. It's also useful in showing you that interrupts have failed.
For the 16-byte transmit buffer, 16 bytes will be transmitted and then it will wait until the next polling takes place (several seconds later) before the next 16 bytes is sent out. Thus transmission is very slow and in small chunks. Receiving is slow too since bytes that are received by the receive buffer are likely to remain there for several seconds until it is polled.
This explains why it takes so long before you see what you typed. When you type say AT to the modem, the AT goes out the serial port to the modem. The modem then echos the AT back thru the serial port to the screen. Thus the AT characters had to pass twice thru the serial port. Normally this happens so fast that AT seems to appear on the screen at the same time that you hit the keys on the keyboard. With polling delays thru the serial port, you don't see what you typed until many seconds later.
What about overruns of the 16-byte receive buffer? This will happen with an external modem since the modem just sends to the serial port at high speed which is likely to overrun the 16-byte buffer. But for an internal modem, the serial port is on the same card and it's likely to check that this receive buffer has room for more bytes before putting received bytes into it. In this case there will be no overrun of this receive buffer, but text will just appear on your screen in 16-byte chunks at intervals of several seconds.
Even with an external modem you might not get overruns. If just a few characters (under 16) are sent you don't get overruns since the buffer likely has room for them. But attempts to send a larger number of bytes from your modem to your screen may result in overruns. However, more than 16 (with no gaps) can get thru OK if the timing is right. For example, if 32 bytes were received (and no more bytes followed), the polling might just happen after the first 16 bytes had been received. Then there would be space for the next 16 bytes so that 32 bytes gets thru OK. Similar conditions might pass between 16 to 31 bytes thru OK. But it's also likely that only an occasional 16-byte chunk will get thru and huge gaps of missing data will be lost.
If you have an obsolete serial port with only a 1-byte buffer (or it's been incorrectly set to work like a 1-byte buffer) then the situation will be much worse than described above and only one character will occasionally make it thru the port. This character is likely to be just a line-feed since this is often the last character to be transmitted in a burst of characters sent to your screen. Thus you may type AT to the modem but never see AT on the screen. All you see several seconds later is that the cursor drops down one line. This has happened to me even with a 16-byte buffer that was somehow behaving like a 1-byte buffer.
When a communication program starts up, it expects interrupts to be working. It's not geared to using this slow polling-like mode of operation. Thus all sorts of mistakes may be made such as setting up the serial port and/or modem incorrectly. It may fail to realize when a connection has been made. If a script is being used for login, it may fail (caused by timeout) due to the polling delays.
When two devices have the same IRQ number it's called sharing interrupts. Under some conditions this sharing works out OK. Starting with kernel version 2.2, serial ports may share interrupts with other serial ports. Devices on the PCI bus may share the same IRQ interrupt with other devices on the PCI bus. In other cases where there is potential for conflict, there should be no problem if no two devices with the same IRQ are ever "in use" at the same time. More precisely, "in use" really means "open" (in programmer jargon). In cases other than the exceptions mentioned above (unless special software permits sharing), sharing is not allowed and conflicts arise if sharing is attempted.
Even if two processes with conflicting IRQs run at the same time, one of the devices will likely have its interrupts sent to its device driver and will work OK. The other device will not have its interrupts sent to the correct driver and will likely behave just like a process with mis-set interrupts. See Interrupt Mis-set for more details.