For the PCI bus look at /proc/pci. For Plug-and-Play modems on the ISA use "pnpdump" (part of isapnptools) to find it. See What is the current I/O address and IRQ of my Serial Port ? You may probe for it using "setserial" with the "autoconfig" argument at the I/O address you think the modem is at. If is shows "unknown" for UART type there may be nothing there. See What is serial. You could possibly have a winmodem (or the like) which can't be used with Linux. See Avoid: Winmodems.
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.
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.
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.
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
getty Or uugetty Still Doesn't Work.
You probably have an IRQ conflict. Make sure there are no IRQs
being shared. Check all your boards (serial, ethernet, SCSI, etc...).
Make sure the jumper settings, and the setserial parameters are
correct for all your serial devices. Also check /proc/ioports
and /proc/interrupts for conflicts.
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.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
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.