The 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 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 can't be used with Linux. See Avoid most software modems 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 to see if there's a modem on a port is to start "minicom" on the port (go to the setup menus with ^AO). Then type "AT" and you should see OK (or 0 if it's set for "digit result codes"). The results may be:
The 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) the modem is not responding (assuming there is really a modem on the port you are typing to).
One reason that a real modem doesn't respond is that it is 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. The kernel may still think you are using the modem although there will be no process ID for it. Thus the message from minicom "You are already online. Hangup first." Well, you are sort of online but you are likely not 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 is to send +++ to the modem to tell it to escape back to "command mode" from "online data mode". The hangup string should do this so you may simply command minicom (or the like) to hangup. You could just type +++ to the modem. You must type it rapidly and be sure to wait a second or two both before and after typing this sequence of 3 plus symbols.
There 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).
Flow 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.
Make sure you are using the correct syntax for your version of
init
. The different init
's that are out there use different
syntax in the /etc/inittab
file. Make sure you are using the
correct syntax for your version of getty
.
Id "S3" is just an example. In this case look on the line which
starts with "S3" in /etc/inittab
. This is causing the problem.
Make sure the syntax for this line is correct and that the device
(ttyS3) exists and can be found.
Make sure your modem is configured correctly. Look at registers
E
and Q
.
This can occur when your modem is chatting with getty
.
If you use uugetty, verify that your /etc/gettydefs
syntax is
correct by doing the following:
linux# getty -c /etc/gettydefs
This can also happen when the uugetty
initialization is failing.
See section
uugetty Still Doesn't Work.
This 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 &D3
, but on his USR Courier, he had to set
&D2
and S13=1
. Check your modem manual (if you have
one).
There is a DEBUG
option that comes with getty_ps
. Edit your
config file
/etc/conf.{uu}getty.ttyS
N and
add DEBUG=
NNN. Where NNN is one of the following
combination of numbers according to what you are trying to debug:
D_OPT 001 option settings
D_DEF 002 defaults file processing
D_UTMP 004 utmp/wtmp processing
D_INIT 010 line initialization (INIT)
D_GTAB 020 gettytab file processing
D_RUN 040 other runtime diagnostics
D_RB 100 ringback debugging
D_LOCK 200 uugetty lockfile processing
D_SCH 400 schedule processing
D_ALL 777 everything
Setting DEBUG=010
is a good place to start.
If you are running syslogd
, debugging info
will appear in your log files. If you aren't running syslogd
info will appear in /tmp/getty:ttyS
N for debugging
getty
and /tmp/uugetty:ttyS
N for uugetty
, and in
/var/adm/getty.log
. Look at the
debugging info and see what is going on. Most likely, you will need
to tune some of the parameters in your config
file, and reconfigure your modem.
You could also try mgetty
. Some people have better luck with
it.
If a device (such as a modem) works on a serial port, then obviously the port has been found. If it doesn't work at all, then you need to make sure your serial port can be found.
Check the BIOS menus and BIOS messages. If it's an ISA bus PnP serial port, try "pnpdump --dumpregs" and/or see Plug-and-Play-HOWTO. For the PCI bus use lspci. You may try probing with setserial. See Probing If nothing seems to get thru the port it may be there but have a bad interrupt. See 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 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 the Serial-HOWTO section: "Interrupt Problem Details".
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 and sometimes drastically decreases your thruput.
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 incorrect information. 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" or run "lspci". Compare this to how Linux (e.g. "setserial") thinks the hardware is set.
One 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. A 56k Modem seldom works at 56k and the Internet often has congestion and bottlenecks that slow things down.
Another possible reason is that the serial driver thinks you have an obsolete serial port (UART 8250,16450 or early 16550). See What Are UARTs?. Use "setserial -g /dev/ttyS*". If it shows anything less than a 16550A, this is likely your problem. Then if "setserial" has it wrong, change it. See What is Setserial for more info. Of course if you really do have an obsolete serial port, lying about it to setserial will only make things worse.
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")
You have to use setserial
to tell Linux the IRQ you are using.
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.
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.
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".
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 261 type "ps 261" to find out what it is. Then if the process is no longer needed, it may be gracefully killed by "kill 261". If it refuses to be killed use "kill -9 261" 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 161 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 261).
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. Sometimes it actually is "busy" but in other cases it erroneously appears to be "busy".
If the DCD signal is sent to a port, that port will think it's
busy. This problem can arise when you are trying to dial out with a modem
when DCD or DTR are not implemented correctly. DCD should only be on
(asserted) when there is an actual connection (ie someone has dialed
in), not when getty
is watching the port. Check to make sure
that your modem is configured to only assert DCD when there is a
connection. DTR should be on (asserted) whenever something is using,
or watching the line, like getty
, kermit
, or some other comm
program.
``resource busy'' 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 "... resource busy" error message. This is
because the kernel only keeps track of what IRQs are actually in use
and conflicts don't happen unless the devices are in use (open).
There are two cases. There may be a real interrupt conflict that is
being avoided. But if setserial has it wrong, there may be no reason
why ttyS2
can't be used, except that setserial erroneously predicts a
conflict. What you need to do is to find the interrupt setserial
thinks ttyS2
is using. This is easier said than done since you can't
use the "setserial" command for ttyS2
since the IRQ for ttyS2 is
supposedly "busy" and you will get the same "... busy" error message.
To fix this either 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 ttyS2
is using then you may look
at /proc/interrupts to find what else is 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).
These are some of the programs you might want to use in troubleshooting: