Subject: sys/arch/i386/isa/com.c: O_NDELAY and DTR broken?
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: Simon J. Gerraty <sjg@zen.void.oz.au>
List: current-users
Date: 01/29/1994 23:02:06
As a step towards updating my NetBSD from the Nov20 snapshot to this
weeks or last (I have last weeks tar_files ready to load onto tape...
and am just waiting for this weeks update), I tried to convert my
system back to using the standard com.c rather than one hacked to
support bidir callout units.  So as to minimize the number of local
hack to be migrated into the new kernel.  I don't suppose my 
LP_SIMPLE_PROBE option made it into the official sources ? (It
causes the super clever lp*probe() that doesn't spot printer devices
on half the machines, to be replaced with the original crappy one that
never fails :-)

Anyway, back to switching from cua* to tty*. By putting:

for u in 0 1 2
do  
	stty -f /dev/tty0$u clocal
done

in /etc/rc.local

I was able to get X and everything else happily talking to the serial
ports using tty0* rather than cua0*

However there appears to be a problem with programs like mgetty (of
mgetty+sendfax) which open the tty port with O_NDELAY.  I watched
mgetty open the port, program the modem and wait for an incoming call
- all without DTR ever being asserted!  I then tried dialing into the
modem from my other modem and mgetty answered the phone ok, but as
soon as DCD was set and the modem goes into data mode - it spots the
lack of DTR and hangs up!

Programing my modem to ignore the state of DTR is possible, but I have
always gone out of my way to buy modems that correctly react to a
host dropping DTR, so I'm quite happy with the way the modem behaves.

I noticed that running stty -a < /dev/tty01 did cause DTR to be
asserted.

But killing mgetty - thus causing a new one to start, resulted in DTR
being lost again.

The same mgetty binary appeared to work perfectly with tty and cua
ports with the other tty driver (with the bidir hacks).

I'll do without dialin access for a few days, and see whether the
latest com.c fixes the problem...

BTW, since NetBSD's com.c does not support callout units, is there an
official uugetty on the way?  I'm quite happy to continue using mgetty
if not, just curious though...

--sjg

Simon J. Gerraty        <sjg@zen.void.oz.au>

#include <disclaimer>   /* imagine something _very_ witty here */


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