Copyright (C) 2000-2012 |
Whole document tree 17. Troubleshooting17.1 My Modem is Physically There but Can't be FoundThe error messages could be something like "No modem detected", "Modem not responding", or (strange) "You are already online" (from Minicom). If you have installed an internal modem (serial port is builtin) or are using an external one and don't know what serial port it's connected to then the problem is to find the serial port. See My Serial Port is Physically There but Can't be Found. This section is about finding out which serial port has the modem on it. There's a program that looks for modems on commonly used serial ports called "wvdialconf". Just type "wvdialconf <a-new-file-name>". It will create the new file as a configuration file but you don't need this file unless you are going to use "wvdial" for dialing. See What is wvdialconf ? Unfortunately, if your modem is in "online data" mode, wvdialconf will report "No modem detected" See No response to AT Your problem could be due to a winmodem (or the like) which usually can't be used with Linux. See Software-based Modems (winmodems). The "setserial program may be used to detect serial ports but will not detect modems on them. Thus "wvdialconf" is best to try first. Another way try to find out if there's a modem on a port is to start "minicom" on the port (after first setting up minicom for the correct serial port --you will need to save the setup and then exit minicom and start it again). Then type "AT" and you should see OK (or 0 if it's set for "digit result codes"). The results may be:
No response to ATThe modem should send you "OK" in response to your "AT" which you type to the modem (using minicom or the like). If you don't see "OK" (and in most cases don't even see the "AT" you typed either) then the modem is not responding (often because what you type doesn't even get to the modem). A common cause is that there is no modem on the serial port you are typing to. For the case of an internal modem, that serial port likely doesn't exist either. That's because the PnP modem card (which has a built-in serial port) has either not been configured (by isapnp or the like) or has been configured incorrectly. See My Serial Port is Physically There but Can't be Found. If what you type is really getting thru to a modem, then the lack of response could be due to the modem being in "online data" mode where it can't accept any AT commands. You may have been using the modem and then abruptly disconnected (such as killing the process with signal 9). In that case your modem did not get reset to "command mode" where it can interact to AT commands. Thus the message from minicom "You are already online. Hangup first." Well, you are sort of online but you are may not be connected to anything over the phone line. Wvdial will report "modem not responding" for the same situation. To fix this as a last resort you could reboot the computer. Another way to try to fix this is to send +++ to the modem to tell it to escape back to "command mode" from "online data mode". On both sides of the +++ sequence there must be about 1 second of delay (nothing sent during "guard time"). This may not work if another process is using the modem since the +++ sequence could wind up with other characters inserted in between them or after the +++ (during the guard time). Ironically, even if the modem line is idle, typing an unexpected +++ is likely to set off an exchange of control packets (that you never see) that will violate the required guard time so that the +++ doesn't do what you wanted. +++ is usually in the string that is named "hangup string" so if you command minicom (or the like) to hangup it might work. Another way to do this is to just exit minicom and then run minicom again.
17.2 "Modem is busy"What this means depends on what program sent it. The modem could actually be in use (busy). Another cause reported for the SuSE distribution is that there may be two serial drivers present instead of one. One driver was built into the kernel and the second was a module. In kppp, this message is sent when an attempt to get/set the serial port "stty" parameters fails. (It's similar to the "Input/output error" one may get when trying to use "stty -F /dev/ttySx"). To get a few of these stty parameters, the true address of the port must be known to the driver. So the driver may have the wrong address. The setserial" command will display what the driver thinks but it's likely wrong in this case. So what the "modem busy" really means is that the serial port (and the modem) can't be found. If you have a pci modem, then use one of these commands: lspci, or cat /proc/pci, or dmesg to find the correct address and irq of the modem's serial port. Then check to see if "setserial" shows the same thing. If not, you need to run a script at boot-time which contains a setserial command that will tell the driver the correct address and irq. The reason that the driver has it wrong may be due to failure of the kernel to understand the lspci data correctly. You might notice this in a boot-time message.
17.3 I can't get near 56k on my 56k modemThere must be very low noise on the line for it to work at even close to 56k. Some phone lines are so bad that the speeds obtainable are much slower than 56k (like 28.8k or even slower). Sometimes extension phones connected to the same line can cause problems. To test this you might connect your modem directly at the point where the telephone line enters the building with the feeds for everything else on that line disconnected (if others can tolerate such a test).
17.4 Uploading (downloading) files is broken/slowFlow control (both at your PC and/or modem-to-modem) may not be enabled. For the uploading case: If you have set a high DTE speed (like 115.2k) then flow from your modem to your PC may work OK but uploading flow in the other direction will not all get thru due to the telephone line bottleneck. This will result in many errors and the resending of packets. It may thus take far too long to send a file. In some cases, files don't make it thru at all. For the downloading case: If you're downloading long uncompressed files or web pages (and your modem uses data compression) or if you've set a low DTE speed, then downloading may also be broken due to no flow control.
17.5 For Dial-in I Keep Getting "line NNN of inittab invalid"Make sure you are using the correct syntax for your version of
17.6 I Keep Getting: ``Id "S3" respawning too fast: disabled for 5 minutes'' Id "S3" is just an example. In this case look on the line which
starts with "S3" in
If you use uugetty, verify that your
This can also happen when the
17.7 My Modem is Hosed after Someone Hangs Up, or uugetty doesn't respawnThis can happen when your modem doesn't reset when DTR is dropped.
Greg Hankins saw his RD and SD LEDs go crazy when this happened.
You need to have your modem reset. Most Hayes compatible modems do
this with
17.8 NO DIALTONEIt means exactly what it says. Someone else may be using another telephone on the same line. You also get this error if there is no phone line plugged into the modem, or if the phone line is somehow broken. Try plugging a real telephone into the phone cord used by the modem. Check it for a dialtone. If for some reason your modem doesn't detect a dialtone, then you can force it to dial anyway by putting X3 in the init string.
17.9 NO CARRIERThis means that the analog sine wave (the carrier) from the other modem isn't present like it should be. If you were already connected, this means that the connection has been lost. There may have been noise on the line or a bad connection. The other modem may have hung up on you for some reason: Perhaps the automatic login process didn't work out OK. Perhaps PPP didn't get started OK. Perhaps a time limit was exceeded. If you get this error before you get connected, it means that the carrier of the other modem wasn't detected by your modem. This may happen if there is there is no properly working modem on the other end. For example, an answering machine could have picked up your call instead of a modem. NO CARRIER will also happen if the modems fail to negotiate a protocol to use. This can happen if you have an early V.90 modem that first tries to negotiate a high speed X2 or K56flex protocol. These two protocols are obsolete and some ISP servers will drop the connection (hang up) when this happens since they have no understanding of such protocols and don't wait around long enough for the calling modem to fallback to V.90. If you force your modem to drop the connection by dropping the DTR signal or sending your modem the hangup signal (ATH) you may get this error message. But in this case you (or your software) wanted to drop the connection so there should be no problem. In this case you are only supposed to get NO CARRIER if data was lost. So for most cases of dropping a connection by hangup (or by dropping DTR) you only get an OK message. Your modem dialer program may not even display that to you.
17.10 uugetty Still Doesn't WorkThere is a
Setting DEBUG=010 is a good place to start.
If you are running You could also try
17.11 (The following subsections are in both the Serial and Modem HOWTOs)17.12 My Serial Port is Physically There but Can't be FoundIf a physical device (such as a modem) doesn't work at all it may mean that the device is not at the I/O address that setserial thinks it's at. It could also mean (for a PnP card) that is doesn't yet have an address. Thus it can't be found. Check the BIOS menus and BIOS messages. For the PCI bus use lspci or
scanpci. If it's an ISA bus PnP serial port, try "pnpdump --dumpregs"
and/or see Plug-and-Play-HOWTO. Using "scanport" will scan all ISA
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 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.13 Extremely Slow: Text appears on the screen slowly after long delaysIt'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
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.14 Somewhat Slow: I expected it to be a few times fasterAn 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
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.15 The Startup Screen Show Wrong IRQs for the Serial 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
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.16 "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 should show 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 ways to get access like belonging to a "group" that has group permission.
17.17 "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.18 "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: usually rwx for everyone (repeated 3 times). If it's wrong, use "chmod" to fix it. Of course, if there is no "lock" directory no lockfile can be created there. For more info on lockfiles see the Serial-HOWTO subsection: "What Are Lock Files".
17.19 "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.20 "/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 (the resource is "busy"). This message is easy to understand if it only means that the device is busy (in use). But it often means that a resource is in use. What makes it even more confusing is that in some cases neither the device nor the resources that it needs are actually "busy". The ``resource busy'' part often means (example for 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:
What you need to do is to find the interrupt setserial thinks
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
17.21 "Input/output error" from setserial or sttyYou may have typed "ttys" instead of "ttyS". You will see this error message if you try to use the setserial command for any device that is not a serial port. 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 could also mean that there isn't any serial port at the IO address that setserial thinks your port is at.
17.22 Overrun errors on serial portThis 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
17.23 Port get characters only sporadicallyThere could be some other program running on the port. Use "top" (provided you've set it to display the port number) or "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.24 Troubleshooting ToolsThese are some of the programs you might want to use in troubleshooting:
Next Previous Contents |