Next Previous Contents

17. Troubleshooting

See Modem-HOWTO for troubleshooting related to modems or getty for modems. For a Text-Terminal much of the info here will be of value as well as the troubleshooting info in Text-Terminal-HOWTO.

17.1 Serial Electrical Test Equipment

Breakout Gadgets, etc.

While a multimeter (used as a voltmeter) may be all that you need for just a few serial ports, simple special test equipment has been made for testing serial port lines. Some are called "breakout ... " where breakout means to break out conductors from a cable. These gadgets have a couple of connectors which connect to serial port connectors (either at the ends of serial cables or at the back of a PC). Some have test points for connecting a voltmeter. Others have LED lamps which light when certain modem control lines are asserted (turned on). The color of the light may indicate the polarity of the signal (positive or negative voltage). Still others have jumpers so that you can connect any wire to any wire. Some have switches.

Radio Shack sells (in 2002) a "RS-232 Troubleshooter" (formerly called "RS-232 Line Tester") Cat. #276-1401. It checks TD, RD, CD, RTS, CTS, DTR, and DSR. A green light means on (+12 v) while red means off (-12 v). They also sell a "RS-232 Serial Jumper Box" Cat. #276-1403. This permits connecting the pins anyway you choose. Both these items are under the heading of "Peripheral hookup helpers". Unfortunately, they are not listed in the index to the printed catalog. They are on the same page as the D type connecters so look in the index under "Connectors, Computer, D-Sub". A store chain named "Active Components" may have them.

Measuring voltages

Any voltmeter or multimeter, even the cheapest that sells for about $10, should work fine. Trying to use other methods for checking voltage is tricky. Don't use a LED unless it has a series resistor to reduce the voltage across the LED. A 470 ohm resistor is used for a 20 ma LED (but not all LED's are 20 ma). The LED will only light for a certain polarity so you may test for + or - voltages. Does anyone make such a gadget for automotive circuit testing?? Logic probes may be damaged if you try to use them since the TTL voltages for which they are designed are only 5 volts. Trying to use a 12 V incandescent light bulb is not a good idea. It won't show polarity and due to limited output current of the UART it probably will not even light up.

To measure voltage on a female connector you may plug in a bent paper clip into the desired opening. The paper clip's diameter should be no larger than the pins so that it doesn't damage the contact. Clip an alligator clip (or the like) to the paper clip to connect up. Take care not to touch two pins at the same time with any metal object.

Taste voltage

As a last resort, if you have no test equipment and are willing to risk getting shocked (or even electrocuted) you can always taste the voltage. Before touching one of the test leads with your tongue, test them to make sure that there is no high voltage on them. Touch both leads (at the same time) to one hand to see if they shock you. Then if no shock, wet the skin contact points by licking and repeat. If this test gives you a shock, you certainly don't want to use your tongue.

For the test for 12 V, Lick a finger and hold one test lead in it. Put the other test lead on your tongue. If the lead on your tongue is positive, there will be a noticeable taste. You might try this with flashlight batteries first so you will know what taste to expect.

17.2 Serial Monitoring/Diagnostics

A few Linux programs will monitor the modem control lines and indicate if they are positive (1) or negative (0). See section Serial Monitoring/Diagnostics

17.3 (The following subsections are in both the Serial and Modem HOWTOs)

17.4 My Serial Port is Physically There but Can't be Found

If a physical device (such as a modem) doesn't work at all it's often because it's disabled and has no address (PnP hasn't enabled it) or that it is enabled but is not at the I/O address that setserial thinks it's at. Thus it can't be found.

First check BIOS messages at boot-time (and possibly the BIOS menu for the serial port). Then for the PCI bus use lspci. If this shows something like "LPC Bridge" then your port is likely on the LPC bus which is not well supported by Linux yet (but the BIOS might find it) ?? If it's an ISA bus PnP serial port, try "pnpdump --dumpregs" and/or see Plug-and-Play-HOWTO. If the port happens to be enabled then the following two paragraphs may help find it:

Using "scanport" (Debian only ??) will scan all enabled bus ports and may discover an unknown port that could be a serial port (but it doesn't probe the port). It could hang your PC. You may try probing with setserial. See Probing.

If nothing seems to get thru the port it may be accessible but have a bad interrupt. See Extremely Slow: Text appears on the screen slowly after long delays. Use setserial -g to see what the serial driver thinks and check for IRQ and I0 address conflicts. Even if you see no conflicts the driver may have incorrect information (view it by "setserial") and conflicts may still exist.

If two ports have the same IO address then probing it will erroneously indicate only one port. Plug-and-play detection will find both ports so this should only be a problem if at least one port is not plug-and-play. All sorts of errors may be reported/observed for devices illegally "sharing" a port but the fact that there are two devices on the same a port doesn't seem to get detected (except hopefully by you). In the above case, if the IRQs are different then probing for IRQs with setserial might "detect" this situation by failing to detect any IRQ. See Probing.

17.5 Extremely Slow: Text appears on the screen slowly after long delays

It's likely mis-set/conflicting interrupts. Here are some of the symptoms which will happen the first time you try to use a modem, terminal, or serial printer. In some cases you type something but nothing appears on the screen until many seconds later. Only the last character typed may show up. It may be just an invisible <return> character so all you notice is that the cursor jumps down one line. In other cases where a lot of data should appear on the screen, only a batch of about 16 characters appear. Then there is a long wait of many seconds for the next batch of characters. You might also get "input overrun" error messages (or find them in logs).

For more details on the symptoms and why this happens see

Interrupt Problem Details and/or Interrupt Conflicts and/or Mis-set Interrupts. If it involves Plug-and-Play devices, see also Plug-and-Play-HOWTO.

As a quick check to see if it really is an interrupt problem, set the IRQ to 0 with "setserial". This will tell the driver to use polling instead of interrupts. If this seems to fix the "slow" problem then you had an interrupt problem. You should still try to solve the problem since polling uses excessive computer resources.

Checking to find the interrupt conflict may not be easy since Linux supposedly doesn't permit any interrupt conflicts and will send you a /dev/ttyS?: Device or resource busy error message if it thinks you are attempting to create a conflict. But a real conflict can be created if "setserial" has told the kernel incorrect info. The kernel has been lied to and thus doesn't think there is any conflict. Thus using "setserial" will not reveal the conflict (nor will looking at /proc/interrupts which bases its info on "setserial"). You still need to know what "setserial" thinks so that you can pinpoint where it's wrong and change it when you determine what's really set in the hardware.

What you need to do is to check how the hardware is set by checking jumpers or using PnP software to check how the hardware is actually set. For PnP run either "pnpdump --dumpregs" (if ISA bus) or run "lspci" (if PCI bus). Compare this to how Linux (e.g. "setserial") thinks the hardware is set.

17.6 Somewhat Slow: I expected it to be a few times faster

An obvious reason is that the baud rate is actually set too slow. It's claimed that this happened by trying to set the baud rate to a speed higher than the hardware can support (such as 230400).

Another reason may be that whatever is on the serial port (such as a modem, terminal, printer) doesn't work as fast as you thought it did.

Another possible reason is that you have an obsolete serial port: UART 8250, 16450 or early 16550 (or the serial driver thinks you do). See

What Are UARTS? Use "setserial -g /dev/ttyS*". If it shows anything less than a 16550A, this may be your problem. If you think that "setserial" has it wrong check it out. See What is Setserial for more info. If you really do have an obsolete serial port, lying about it to setserial will only make things worse.

17.7 The Startup Screen Show Wrong IRQs for the Serial Ports.

For non-PnP ports, Linux does not do any IRQ detection on startup. When the serial module loads it only does serial device detection. Thus, disregard what it says about the IRQ, because it's just assuming the standard IRQs. This is done, because IRQ detection is unreliable, and can be fooled. But if and when setserial runs from a start-up script, it changes the IRQ's and displays the new (and hopefully correct) state on on the startup screen. If the wrong IRQ is not corrected by a later display on the screen, then you've got a problem.

So, even though I have my ttyS2 set at IRQ 5, I still see 

ttyS02 at 0x03e8 (irq = 4) is a 16550A
at first when Linux boots. (Older kernels may show "ttyS02" as "tty02" which is the same as ttyS2). You may need to use setserial to tell Linux the IRQ you are using.

17.8 "Cannot open /dev/ttyS?: Permission denied"

Check the file permissions on this port with "ls -l /dev/ttyS?"_ If you own the ttyS? then you need read and write permissions: crw with the c (Character device) in col. 1. It you don't own it then it will work for you if it shows rw- in cols. 8 & 9 which means that everyone has read and write permission on it. Use "chmod" to change permissions. There are more complicated (and secure) ways to get access like belonging to a "group" that has group permission. Some programs change the permissions when they run but restore them when the program exists normally. But if someone pulls the plug on your PC it's an abnormal exit and correct permissions may not be restored.

17.9 "Operation not supported by device" for ttyS?

This means that an operation requested by setserial, stty, etc. couldn't be done because the kernel doesn't support doing it. Formerly this was often due to the "serial" module not being loaded. But with the advent of PnP, it may likely mean that there is no modem (or other serial device) at the address where the driver (and setserial) thinks it is. If there is no modem there, commands (for operations) sent to that address obviously don't get done. See What is set in my serial port hardware?

If the "serial" module wasn't loaded but "lsmod" shows you it's now loaded it might be the case that it's loaded now but wasn't loaded when you got the error message. In many cases the module will automatically loaded when needed (if it can be found). To force loading of the "serial" module it may be listed in the file: /etc/modules.conf or /etc/modules. The actual module should reside in: /lib/modules/.../misc/serial.o.

17.10 "Cannot create lockfile. Sorry"

When a port is "opened" by a program a lockfile is created in /var/lock/. Wrong permissions for the lock directory will not allow a lockfile to be created there. Use "ls -ld /var/lock" to see if the permissions are OK. Giving rwx permissions for the root owner and the group should work, provided that the users that need to dialout belong to that group. Others should have r-x permission. Even with this scheme, there may be a security risk. Use "chmod" to change permissions and "chgrp" to change groups. Of course, if there is no "lock" directory no lockfile can be created there. For more info on lockfiles see What Are Lock Files

17.11 "Device /dev/ttyS? is locked."

This means that someone else (or some other process) is supposedly using the serial port. There are various ways to try to find out what process is "using" it. One way is to look at the contents of the lockfile (/var/lock/LCK...). It should be the process id. If the process id is say 100 type "ps 100" to find out what it is. Then if the process is no longer needed, it may be gracefully killed by "kill 100". If it refuses to be killed use "kill -9 100" to force it to be killed, but then the lockfile will not be removed and you'll need to delete it manually. Of course if there is no such process as 100 then you may just remove the lockfile but in most cases the lockfile should have been automatically removed if it contained a stale process id (such as 100).

17.12 "/dev/tty? Device or resource busy"

This means that the device you are trying to access (or use) is supposedly busy (in use) or that a resource it needs (such as an IRQ) is supposedly being used by another device and can't be shared. This message is easy to understand if it only means that the device is busy (in use). But it sometimes means that a needed resource is already in use (busy). What makes it even more confusing is that in some cases neither the device nor the resources that it needs are actually "busy".

In olden days, if a PC was shutdown by just turning off the power, a bogus lockfile might remain and then later on one would get this bogus message and not be able to use the serial port. Software today is supposed to automatically remove such bogus lockfiles, but as of 2003 there is still a problem with the "wvdial" dialer program related to lockfiles. If wvdial can't create a lockfile because it doesn't have write permission in the /var/lock/ directory, you will see this erroneous message.

The following example is where interrupts can't be shared (at least one of the interrupts is on the ISA bus). The ``resource busy'' part often means (example for ttyS2) ``You can't use ttyS2 since another device is using ttyS2's interrupt.'' The potential interrupt conflict is inferred from what "setserial" thinks. A more accurate error message would be ``Can't use ttyS2 since the setserial data (and kernel data) indicates that another device is using ttyS2's interrupt''. If two devices use the same IRQ and you start up only one of the devices, everything is OK because there is no conflict yet. But when you next try to start the second device (without quitting the first device) you get a "... busy" error message. This is because the kernel only keeps track of what IRQs are actually in use and actual conflicts don't happen unless the devices are in use (open). The situation for I/O address (such as 0x3f8) conflict is similar.

This error is sometimes due to having two serial drivers: one a module and the other compiled into the kernel. Both drivers try to grab the same resources and one driver finds them "busy".

There are two possible cases when you see this message:

  1. There may be a real resource conflict that is being avoided.
  2. Setserial has it wrong and the only reason ttyS2 can't be used is that setserial erroneously predicts a conflict.

What you need to do is to find the interrupt setserial thinks ttyS2 is using. Look at /proc/tty/driver/serial. You should also be able to find it with the "setserial" command for ttyS2.

Bug in old versions: Prior to 2001 there was a bug which wouldn't let you see it with "setserial". Trying to see it would give the same "... busy" error message.

To try to resolve this problem reboot or: exit or gracefully kill all likely conflicting processes. If you reboot: 1. Watch the boot-time messages for the serial ports. 2. Hope that the file that runs "setserial" at boot-time doesn't (by itself) create the same conflict again.

If you think you know what IRQ say ttyS2 is using then you may look at /proc/interrupts to find what else (besides another serial port) is currently using this IRQ. You might also want to double check that any suspicious IRQs shown here (and by "setserial") are correct (the same as set in the hardware). A way to test whether or not it's a potential interrupt conflict is to set the IRQ to 0 (polling) using "setserial". Then if the busy message goes away, it was likely a potential interrupt conflict. It's not a good idea to leave it permanently set at 0 since it will put more load on the CPU.

17.13 "Input/output error" from setserial, stty, pppd, etc.

This means that communication with the serial port isn't working right. It could mean that there isn't any serial port at the IO address that setserial thinks your port is at. It could also be an interrupt conflict (or an IO address conflict). It also may mean that the serial port is in use (busy or opened) and thus the attempt to get/set parameters by setserial or stty failed. It will also happen if you make a typo in the serial port name such as typing "ttys" instead of "ttyS".

17.14 "LSR safety check engaged"

LSR is the name of a hardware register. It usually means that there is no serial port at the address where the driver thinks your serial port is located. You need to find your serial port and possibly configure it. See Locating the Serial Port: IO address IRQs and/or What is Setserial

17.15 Overrun errors on serial port

This is an overrun of the hardware FIFO buffer and you can't increase its size. Bug note (reported in 2002): Due to a bug in some kernel 2.4 versions, the port number may be missing and you will only see "ttyS" (no port number). But if devfs notation such as "tts/2" is being used, there is no bug. See Higher Serial Thruput.

17.16 Port gets characters only sporadically

There could be some other program running on the port. Use "top" (provided you've set it to display the port number) or type "ps -alxw". Look at the results to see if the port is being used by another program. Be on the lookout for the gpm mouse program which often runs on a serial port.

17.17 Troubleshooting Tools

These are some of the programs you might want to use in troubleshooting:

17.18 Almost all characters are wrong; Many missing or many extras

Perhaps a baud mismatch. If one port sends at twice the speed that the other port is set to receive, then every two characters sent will be received as one character. Each bit of this received character will be a sample of two bits of what is sent and will be wrong. Also, only half the characters sent seem to get received. For flow in the reverse direction, it's just the opposite. Twice as many characters get received than were sent. A worse mismatch will produce even worse results.

A speed mismatch is not likely to happen with a modem since the modem autodetects the speed. One cause of a mismatch may be due to serial port hardware that has been set to run at very fast speeds. It may actually operate at a speed say 8 times that of which you (or an application) set it via software. See Very High Speeds

Next Previous Contents

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:36