Next Previous Contents

15. Troubleshooting

15.1 I can't get 56K on my 56K modem

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 check this you might try connecting your modem directly to the point where the telephone line enters the building with the feed for everything else on that line disconnected (if others can tolerate that).

15.2 Uploading (downloading) files is broken/slow

Flow control (both at your PC and/or modem) may not be enabled. If you have set a high DTE speed (like 115.2K) then flow from your modem to your PC may work OK but a lot of 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. If you're downloading long uncompressed files or web pages (and your modem uses data compression) or you've set a low DTE speed, then downloading may also be broken due to no flow control.

15.3 For Dial-in I Keep Getting "line NNN of inittab invalid"

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.

15.4 When I Try To Dial Out, It Says "/dev/ttySN: Device or resource busy"

This problem can arise 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.

Another common cause of ``device busy'' errors, is that you set up your serial port with an interrupt already taken by something else. As each device initializes, it asks Linux for permission to use its hardware interrupt. Linux keeps track of which interrupt is assigned to whom, and if your interrupt is already taken, your device won't be able to initialize properly. The device really doesn't have much of any way to tell you that this happened, except that when you try to use it, it will return a ``device-busy'' error. Check the interrupts on all of your boards (serial, ethernet, SCSI, etc.). Look for IRQ conflicts.

15.5 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 /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.

15.6 My Modem is Hosed after Someone Hangs Up, or uugetty doesn't respawn

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).

15.7 uugetty Still Doesn't Work

There is a DEBUG option that comes with getty_ps. Edit your config file /etc/conf.{uu}getty.ttySN 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:ttySN for debugging getty and /tmp/uugetty:ttySN 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.

15.8 My Modem is Physically There but Can't be Found

If you know about the existing serial ports before you installed an internal modem, then the problem is to find the new serial port. This is covered in the next section. 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 ?

Your problem could be due to a winmodem (or the like) which can't be used with Linux. See Avoid: 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 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"). If it takes many seconds to get a response (including only the cursor moving down one line) then see Slow: Text appears on the screen slowly after long delays

15.9 The following subsections are in both the Serial and Modem HOWTOs:

15.10 My Serial Port is Physically There but Can't 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 look at /proc/pci. 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 Slow: Text appears on the screen slowly after long delays

15.11 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 (and it may be just an invisible <return> character but you notice 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".

As a final check to see if it really is an interrupt problem, set the IRQ to zero with "setserial". This will tell the driver not to use interrupts but to use inefficient (but faster) polling methods. If this seemingly fixes the "slow" problem then you had an interrupt problem but should still try to fix it since polling uses excessive computer resources.

Checking to find the interrupt conflict may not be easy since looking in the /proc directory may be misleading. Make sure there are no IRQs being illegally shared. Check all your boards (serial, ethernet, SCSI, etc...). Make sure the jumper (or PnP) settings, and the setserial parameters are correct for all your serial devices. Also check /proc/ioports and /proc/interrupts and /proc/pci for conflicts. For more details see Serial-HOWTO: Interrupt Problem Details. If it involves Plug-and-Play devices, see also Plug-and-Play-HOWTO.

15.12 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 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.

15.13 "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.

15.14 "Operation not supported by device" (error message) for ttySx

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.

15.15 "Cannot create lockfile. Sorry" (error message)

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".

15.16 Software which may help


Next Previous Contents