New HOWTO: Modem-HOWTO - page 17

Table of Contents

  16.  Troubleshooting

  16.1.  My Modem is Physically There but Can't be Found

  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 (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 ".  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.  See ``No response to AT''

  �  It takes many seconds to get an expected truncated response
     (including only the cursor moving down one line).  See ``Extremely
     Slow: Text appears on the screen slowly after long delays''

  �  Some strange characters appear but they are not in response to AT.
     This likely means that your modem is still connected to something
     at the other end of the phone line which is sending some cryptic
     packets or the like.


  16.1.1.  No response to AT

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


  16.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 parameters fails.  These parameters are the one you see if you
  give the "stty -a" command.  It's similar to the "Input/output error"
  one may get when trying to use "stty -F /dev/ttySx".  Although the
  port is already opened when you see this message, I think it's
  possible to open a non-existent device (or one with the wrong IRQ or
  IO address).  Now getting certain port parameters (such as the speed)
  means communicating with the serial port hardware.  So this error
  message may mean that there is no serial port there (or that the
  modem's serial port has an incorrect (or no) IRQ or I0 address.  It
  could be a wrong ttySx number.  If /dev/modem is used it should be
  linked to the correct ttySx.  In these cases the error message should
  have said: "Modem can't be found" which really means that it's serial
  port (often built into the modem) can't be found.


  16.3.  I can't get near 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 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).


  16.4.  Uploading (downloading) files is broken/slow

  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.


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


  16.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 /etc/inittab and calls getty.  This line causes
  the problem.  Make sure the syntax for this line is correct and that
  the device (ttyS3) exists and can be found.  If the modem has negated
  CD and getty opens the port, you'll get this error message since
  negated CD will kill getty.  Then getty will respawn only to be killed
  again, etc.  Thus it respawns over and over (too fast).  It seems that
  if the cable to the modem is disconnected or you have the wrong serial
  port, it's just like CD is negated.  All this can occur when your
  modem is chatting with getty.  Make sure your modem is configured
  correctly.  Look at AT commands E and Q.


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


  16.7.  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 for USR Courier, SupraFax, and other modems, you must
  set &D2 (and S13=1 for USR Courier).  Check your modem manual (if you
  have one).


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


  16.9.  (The following subsections are in both the Serial and Modem
  HOWTOs)

  16.10.  My Serial Port is Physically There but Can't be Found

  If 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 setserial -g to see what the serial driver thinks and
  check for IRQ and I0 address conflicts.  Even if you see no conflicts
  the driver may have incorrect information (view it by "setserial" and
  conflicts may still exist.

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


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

  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.


  16.12.  Somewhat Slow: I expected it to be a few times faster

  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.  If the modem on the other end
  does not have a digital connection to the phone line (and uses a
  special "digital modem" not sold in most computer stores), then speeds
  above 33.6k are not possible.

  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" in the Serial-HOWTO.

  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.


  16.13.  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" which is the same as ttyS2).  You may need to use setserial to
  tell Linux the IRQ you are using.


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


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


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


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


  16.18.  "/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
  not the resources that it needs are actually "busy".

  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:

  1. There may be a real resource conflict that is being avoided.

  2. Setserial has it wrong and the only reason 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 (if you have it).  You should
  also be able to find it with the "setserial" command for ttyS2.   But
  due to a bug (reported by me in Nov. 2000) you get the same "... busy"
  error message when you try this with "setserial".

  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 conflcit.  It's not a good idea to leave it
  permanently set at 0 since it will make the CPU work too hard.

  16.19.  "Input/output error" from setserial or stty

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


  16.20.  Overrun errors on serial port

  This is an overrun of the hardware FIFO buffer and you can't increase
  its size.  See "Higher Serial Thruput" in the Serial-HOWTO.


  16.21.  Modem doesn't pick up incoming calls

  This paragraph is for the case where a modem is used for both dial-in
  and dial-out.  If the modem generates a DCD (=CD) signal, some
  programs (but not mgetty) will think that the modem is busy.  This
  will cause a problem when you are trying to dial out with a modem and
  the modem's DCD or DTR are not implemented correctly.  The modem
  should assert DCD only 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 (&C1).  DTR should be on (asserted) by the communications
  program whenever something is using, or watching the line, like getty,
  kermit, or some other comm program.


  16.22.  Port get characters only sporadically

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


  16.23.  Troubleshooting Tools

  These are some of the programs you might want to use in
  troubleshooting:

  �  "lsof /dev/ttyS*" will list serial ports which are open.

  �  "setserial" shows and sets the low-level hardware configuration of
     a port (what the driver thinks it is).  See ``What is Setserial''

  �  "stty" shows and sets the configuration of a port (except for that
     handled by "setserial").  See the Serial-HOWTO section: "Stty".

  �  "modemstat" or "statserial" will show the current state of various
     modem signal lines (such as DTR, CTS, etc.)

  �  "irqtune" will give serial port interrupts higher priority to
     improve performance.

  �  "hdparm" for hard-disk tuning may help some more.

  �  "lspci" shows the actual IRQs, etc. of hardware on the PCI bus.

  �  "pnpdump --dumpregs" shows the actual IRQs, etc. of hardware for
     PnP devices on the ISA bus.

  �  Some "files" in the /proc tree (such as ioports, interrupts, and
     tty/driver/serial).