Next Previous Contents

12. Troubleshooting

12.1 Software

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

For the PCI bus look at /proc/pci. Otherwise see What is the current I/O address and IRQ of my Serial Port ?

Here are some common mistakes people make:

You may probe for the modem's serial port using "setserial" with the "autoconfig" argument at the I/O address you think the modem is at. If it shows "unknown" for UART type there may be nothing there. See What is Setserial. Your problem could be due to a winmodem (or the like) which can't be used with Linux. See Avoid: winmodems.

12.3 "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. A common reason is that the "serial" module wasn't loaded at the time. "lsmod" will show you if it's now loaded but it sometimes is automatically loaded when needed so it may be loaded now but wasn't loaded when you got the error message. The "serial" module should be listed in the file: /etc/modules.conf. The actual module should reside in: /lib/modules/.../misc/serial.o.

12.4 Slow: Text appears on the screen slowly after long delays

This will happen from the very start of using the modem. One symptom happens when you are manually typing to your modem: You type but the screen remains blank (until after several seconds when you finally might see what you typed). Another symptom is that only a few words at a time appear on the screen (possibly with missing text).

This may be due to a mis-set IRQ. This means that the IRQ used by the device driver does not correspond to the IRQ set in hardware (IRQ mis-set). With a mis-set IRQ you may loose received data and get "input overrun" error messages (or find them in logs). See Interrupt Mis-set for more details.

It could also be an interrupt conflict. See Interrupt Conflicts Make sure there are no IRQs being 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.

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

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

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

12.8 I Keep Getting ``Getty respawning too fast: disabled for 5 minutes''

Make sure your modem is configured correctly. Look at registers E and Q. This can occur when your modem is chatting with getty.

Make sure you are calling getty correctly from your /etc/inittab. Using the wrong syntax or device names will cause serious problems.

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

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

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


Next Previous Contents