Hardware manual

internal modem, the serial port is on the same card and it's likely to check that this 16-byte 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 spaced 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

without overruns if the timing is right. For example, suppose a burst of 32 bytes is sent into the port from the

external cable. The polling might just happen after the first 16 bytes came in so it would pick up these 16

bytes OK. Then there would be space for the next 16 bytes so that entire 32 bytes gets thru OK. While this

scenario is not very likely, similar cases where 17 to 31 bytes make thru are more likely. But it's even more

likely that only an occasional 16-byte chunk will get thru with possible loss of data.

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. Every character received causes an overrun (and is lost) except for the last character

received. 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<return> to the modem but never see AT on

the screen. All you see several seconds later is that the cursor drops down one line (a line feed). This has

happened to me with a 16-byte FIFO buffer that was 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

17.4 Interrupt Conflicts

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, ISA serial ports may, if the hardware is designed for

this, share interrupts with other serial ports. Devices on the PCI bus may share the same IRQ interrupt with

other devices on the PCI bus (provided the software supports this). 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 and hardware permit 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 caught by its device driver and may work OK. The other device will not have its interrupts caught

by the correct driver and will likely behave just like a process with mis-set interrupts. See Mis-set Interrupts

for more details.

17.5 Resolving Interrupt Problems

If you are getting a very slow response as described above, then one test is to change the IRQ to 0 (uses fast

polling instead of interrupts) and see if the problem goes away. Note that the polling due to IRQ=0 is orders of

magnitude faster than the slow "polling" due to bad interrupts. If IRQ=0 seems to fix the problem, then there

was likely something wrong with the interrupts. Using IRQ=0 is very resource intensive and is only a

temporary fix. You should try to find the cause of the interrupt problem and not permanently use IRQ=0.

Serial HOWTO

17.3 Mis-set Interrupts 67