Date: Thu, 6 Feb 1997 10:12:18 +0200 (EET) From: Andrew Stesin <stesin@gu.net> To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Strange(!!) sio callin/callout behaviour in 2.1.6 Message-ID: <Pine.BSI.3.95.970206092457.24481A-100000@creator.gu.kiev.ua> In-Reply-To: <199702060648.RAA10833@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Bruce,
On Thu, 6 Feb 1997, Bruce Evans wrote:
> >1. pppd never seems to receive/handle a SIGHUP from modem.
>
> Perhaps the modem never hangs up.
Can't be an issue. Tried several modems, all with
"DCD normal" option turned on (&C1). Other modem's
settings also seem to be appropriate.
> This means that something has /dev/ttyd5 open. Perhaps getty succeeds
> in opening a few microseconds after pppd closes /dev/cuaa5.
No pppd in the above example...
Now after a clean reboot, with a modem but no getty:
# stty -a -f /dev/cuaa1
[... works ...]
# stty -a -f /dev/ttyd1
[... works ...]
# stty -a -f /dev/cuaa1
[... works ...]
# stty -a -f /dev/ttyd1
[... works ...]
Ok. Now adding getty with :hc: in the gettytab entry for
this line:
# vi /etc/ttys
[... off -> on ...]
# kill -1 1
[... DTR LED now is "on" at the modem...]
# stty -a -f /dev/cuaa1
[... works ...]
# stty -a -f /dev/ttyd1
[... works ...]
# stty -a -f /dev/cuaa1
stty: /dev/cuaa1: Device busy
[... several attempts within a few minutes, with the same effect ...]
# stty -a -f /dev/ttyd1
[... still works! ...]
Ok, let's turn getty off back again...
# vi /etc/ttys
[... on->off ...]
# kill -1 1
[... wonder!!! DTR LED on the modem is still on!
Hey I didn't launch anything but the poor getty!!! ...]
# ps auwx|less
[... thorough investigation of processes -- shows nothing
neither on ttyd1 nor on cuaa1 ports. =8-?????? ...]
# cu -l /dev/cuaa1 -s 57600
cu: /dev/cuaa1: Line in use
# cu -l /dev/ttyd1 -s 57600
cu: open (/dev/ttyd1): Permission denied
cu: /dev/ttyd1: Line in use
# id
uid=0(root) gid=0(wheel) [...blah-blah...]
Ok, powercycle the modem. DTR LED is on back again!
And still no processes seen...
> getty sleeps until carrier is present,
Never was in the example above. (BTW: does sio.c pay
any attention to other modem control lines? DSR i.e.?)
> but no longer, so if the port is shared between
> a getty and a dialout program like pppd
Plain stty -a -f ... no dialout.
> and the dialout program closes
> the dialout port before carrier drops, then the getty will grab the port.
> HUPCL on the dialout port
Present
> and a sufficiently large dtrwait should prevent
dtrwait is 400
> this from happening if the modem responds to DTR dropping sufficent quickly.
yes it does (this is Motorola Premier 33.6, nice beast)
>
> Bruce
>
--
Best,
Andrew Stesin
nic-hdl: ST73-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.970206092457.24481A-100000>