From owner-freebsd-hackers Thu Feb 6 00:16:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA10187 for hackers-outgoing; Thu, 6 Feb 1997 00:16:29 -0800 (PST) Received: from whale.gu.kiev.ua (whale.gu.net [194.93.190.4]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10129; Thu, 6 Feb 1997 00:16:14 -0800 (PST) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [194.93.190.3]) by whale.gu.kiev.ua (8.8.5/8.7.3) with SMTP id KAA36544; Thu, 6 Feb 1997 10:12:19 +0200 Date: Thu, 6 Feb 1997 10:12:18 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua Reply-To: Andrew Stesin To: Bruce Evans cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Strange(!!) sio callin/callout behaviour in 2.1.6 In-Reply-To: <199702060648.RAA10833@godzilla.zeta.org.au> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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