Very Computer

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

Thanks for any help.

                                  -- Michael/Virus
.

Like a lot of replies on these groups I am not answering
the first question, I am adding to it.  We bought 2 US Robotics
28.8 (33.3) Sportsters 3 months ago.  We bought them as replacements for
2 US Robotics 14.4 modems, but have not been able to get the new modems
to work under linux properly.  They dial out fine, we just can't
get them to answer properly.  We thought dip or ppp was to blame, but
when we went back to basics (kermit or seyon) we found that we
could only connect once (after a soft-reboot from Win95) and then
we would not be able to connect again.
        Sometimes we get the INIT respawn error, sometimes we don't.
The modems are not getting configured properly, and I don't know how
to fix it.  I am thinking it might be a problem configuring the
serial port or just finding the right init string to put in
/etc/default/uugetty.ttySx.
        Does anyone have these modems working as ppp and/or dip
servers.  Could you email or post your init strings.

        Thanks

Here is my modem init string in Linux:

  AT&F1&A3&B1&C1&D2&I0&H1&R2&K3&M4&S0&S1S0=0S13=1X4E1Q0V1

I also do (in the chatscript):

setserial /dev/cua1 spd_vhi

stty 115200 -tostop

This is how I invoke pppd:

 pppd asyncmap 0 -detach modem crtscts defaultroute noipdefault \
 mru 1500 /dev/$DEVICE 115200

I get 26400-31200 bps connection.

--

: > We bought 2 US Robotics
: > 28.8 (33.3) Sportsters 3 months ago.  
: ...
: >         Does anyone have these modems working as ppp and/or dip
: > servers.  Could you email or post your init strings.
: ..


:
:
: I use USR Sportster external 28.8/33.6 modem.
: It works fine with both Win95 and Linux. I am running
: Linux kernel 2.0.12. But the same setup worked in 1.2.13
: as well.
:
: Here is my modem init string in Linux:
:
:   AT&F1&A3&B1&C1&D2&I0&H1&R2&K3&M4&S0&S1S0=0S13=1X4E1Q0V1

My setup string is a bit simpler:
AT ZT4 E0 M3 S0=0 S7=180 X4 &C1 &D2

:
: ...
: I get 26400-31200 bps connection.
:
: --

--
-------- Thomas Bullinger ------- Specializing in Linux systems --------
* Installation * Setup * Maintenance * Training * Software * Information

* WWW:   http://btoy1-gw.roc.servtech.com/users/consult

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

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
lockfiles anyhow.

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

-----------------------

vern

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