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.
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.
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.
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.
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
There are 3 possibilities:
First check BIOS messages at boot-time (and possibly the BIOS menu for the serial port). Then for the PCI bus type lspci -v. 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 the IO port:
This is mainly for legacy non-PCI ports and ISA ports that are not Plug-and-Play.
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. If you suspect that your port may be at a certain address, you may try manually probing with setserial, but it's a slow tedious task if you have several addresses to probe. See Probing.
If your PC has a BIOS that handles ISA (and likely PCI too) then if you find a IRQ conflict, it might be due to a shortage of free IRQs. The BIOS often maintains a list of reserved IRQs, reserved for legacy ISA cards. If too many are reserved, the BIOS may not be able to find a free IRQ and will erroneously assign an IRQ to the serial port that creates a conflict. So check to see if all the reserved IRQs are really needed and if not, unreserve an IRQ that the serial port can use. For more details, see Plug-and-Play-HOWTO.
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 the 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.
An obvious reason is that the baud rate is set too slow. It's claimed that this once 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.
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
setserial to tell Linux the IRQ you are using.
See /dev/tty? Device or resource busy
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.
Unless stty is set for clocal, the CD pin may need to be asserted in order to open a serial port. If the physical port is not connected to anything, or if it's connected to something that is not powered on (such an external modem) then there will be no voltage on CD from that device. Thus the "cannot open" message. Either set clocal or connect the serial port connector to something and power it on.
Even if a device is powered on and connected to a port, it may sometimes prevent opening the port. An example of this is where the device has negated CD and the CD pin on your PC is negated (negative voltage).
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.
Sometimes when it can't create a lockfile you get the erroneous message: "... Device or resource busy" instead of the one above. 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
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).
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 2006 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. See Cannot create lockfile. Sorry
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:
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.
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".
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
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" was being used, there was no bug. See Higher Serial Thruput.
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.
These are some of the programs you might want to use in troubleshooting:
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