>Hi. I am (2) TWO US Robotics Internal Sporsters (28.8k).
>Linux finds the modems w/o any problems, however, after about 2 mins
>after the login screen comes up, a error: INIT: 'd1' is respawning too
>fast. disabled for 5 minutes.
>Is there anyway to fix this bug? (I am only using one modem in the
>/etc/inittab file before I attempt the other modem).
This is a problem about how your 'getty' was written and how your modem is
Read my 'modems.blurb'. It is part of a collection of serial port
utilities and associated info. The name of the collection is
'serial_suite.tgz' and is available via ftp from 'scicom.alphacdc.com'.
You should also study the docs which accompany 'mgetty'. Some of the
requirements differ from "standard" getty's.
Don't use 'cua*' or '/dev/modem' for outgoing calls.
Try my 'getty_em' from 'serial_suite.tgz'.
Two different methods have been developed in an attempt to avoid having
more than one process running on the same serial port at a time. One
method was developed at AT&T by their uucico developers. The other was
apparently developed at Berkely for the BSD system. This method was
adopted by Sun and others including Linux.
Under the AT&T Unix, the problem was solved by using 'lockfiles'. These
are simple files which contain the PID of the process using the port. The
idea is that if the PID which created the lockfile is still active, other
processes should wait. On Linux. these lockfiles are kept in the
/var/lock/uucp directory. The names are 'LCK..ttyS0' etc. Under this
system, only one device driver is used per port.
When a process wants to use the port, it first checks for a lockfile on the
device it wants to use. If it find a file, it reads the PID recorded
therein and checks if the process is still active or not. If the process
still exists, the new process quits. If the old process has died, the
lockfile is removed and a new one created.
The technique for creating lockfiles is to first create a temporary file
complete with the PID written to it. This file is then linked to the
desired 'LCK..ttySN' name. If some other process also wants this port and
has created their own lockfile, our link will fail.
Under the BSD/Sun versions of Unix, two device drivers are provided for
each port. Presumably one is for 'outgoing' calls and the other for
'incoming' calls. Under Linux, these drivers use the same coding and are
identical except for a kernel lock. The operation of this locking method
is very complicated and I am not sure I know all the side effects even
though I have studied the code extensively.
First, it is necessary to understand that the 'open(2)' system call has a
special flag when the file is a bolck special or character special device
driver. This flag is 'O_NONBLOCK' or 'O_NDELAY'. With respect to serial
devices, this means that a normal 'open' will block and not return until
the Data Carrier Detect (DCD) line is asserted. If 'O_NONBLOCK' flag is
included in the open command, the call will return immediately regardless
of the status of the DCD line.
If the struct termios CLOCAL (see termios.blurb) option has been selected,
the O_NONBLOCK flag is ignored.
In Linux, whenever the NORMAL (ttySN) device is neither open nor blocking
on an open and an attempt is made to open the CALLOUT (cuaN) device, it
will open immediately regardless of the presence or absence of the
O_NOBLOCK flag. However if the NORMAL device is active or blocking on a
read (see VMIN=1, VTIM=0 in 'termios.blurb'), an open on the CALLOUT device
will fail and return an EBUSY error code.
On the other hand, if the CALLOUT device is open (O_NONBLOCK doesn't
appear to be a factor), an attempt to open the NORMAL driver will fail and
return the EBUSY error code.
Thus, if you have a 'getty' listening on the 'incoming' line, it is
impossible to place a call on the 'outgoing' driver. However, if you place
your outgoing call on the 'incoming' driver, it will open and proceed
normally. That is 'normally', if the 'getty' is smart enough to get off
the line. The AT&T 'uugetty' (not the Linux uugetty) expect that the first
characters received on incoming calls are either newlines or carriage
returns. If any other characters are received, they are assumed to be
outgoing characters and the 'getty' graciously exits.
I have been carrying on a discussion for the last couple of months about the
need for 'cuaN and ttySN' drivers and so far I haven't received a
convincing reason that there is an need for the 'cuaN' series. All the
communication software provided with Linux, recognize the /var/lock/uucp
I hope that this clarifies the situation somewhat. As far as I am
concerned, the only value the 'cuaN' and the 'Serial-HOWTO' is to confuse
immigrants from DOS. I immigrated from AT&T SYSV and it confused me.
If you try to open a callout driver when the associated 'callin' driver is
opened, the open returns EBUSY. If the normal driver is opened in blocking
mode, and the callout driver is busy, the attempt to open will fail with
EBUSY. However, if it opened in standard (blocking) mode, the open will
block until the ports DCD line is asserted. For non-blocking mode and the
cuaN port is inactive, the open will succeed immediately.
The problem is partly cultural and partly an attempt to state a complex
situation in simply words.
The problem is "How to prevent incoming call and outgoing calls on a single
port from colliding".
Vernon C. Hoxie scicom!zebra!vern
Denver, Colo., 80212 uucp: 303-455-2670 voice: 303-477-1780
Unix is what MSDOS will be when it grows up.