DTR and the FAS serial driver

[Uwe Doering]

curt at cynic.wimsey.bc.ca (Curt Sampson) writes:

>I've just installed the FAS serial driver on my SCO Xenix 2.3.2
>(286) system.  It's version 2.08, which is the latest, I believe.

Yes, it's the latest.

>Now, the driver works fine for the most part, including enabling
>the FIFO on my 16550A UART.  (No most lost characters at 38.4 Kbps.
>Yea!  :-))
>
>However, it seems that the driver just ignores DTR completely.  It
>doesn't raise it on open nor toggle it when given an B0 in an ioctl.
>This, of course, is a pretty severe problem because most modems
>won't pick up the phone if DTR is not present.
>
>I've added a couple of lines to the driver in an attempt to fix
>this problem.  Here's what the last bit of fas_open_device in fas.c
>looks like (my the line I added is around line 2750, and is preceeded
>by a "cjs" comment):
>
> [excerpt from fas.c deleted]

There is no need to patch FAS. Didn't it occure to you that if there
were a bug in such a basic mechanism like the assertion of DTR I would
have never posted FAS 2.08? Or at least that it would have been fixed
long ago?

I would have appreciated it if you would have mailed me your problems
so that I would have been able to help you. Instead, you prefered
to confuse people by posting a sort-of patch that clearly demonstrates
that you didn't understand the innards of FAS.

There is, of course, a mechanism in FAS to raise and drop DTR. You
failed to understand that these lines are _not_ hardwired inside
FAS, but are rather coded in bit masks settable in the space.c
file. This enables you to freely configure the control lines
FAS should use without having to hack the source code. You wouldn't
even need to have the sources for FAS and would still be able to
configure everything you want.

As you didn't give us details of what is in your space.c file,
I'd guess that you have misconfigured some initializations for
at least the fas_modem[] array. Look at the sample space-* files
and fas.h for an explanation of the available initialization macros.

If you didn't change the defaults in space.c, then there has to
be some other reason why this doesn't work. But at least it
wont be that I simply forgot to provide a mechanism for DTR.

On the other hand, I don't claim that FAS is bug free. But if
you think you found a bug, please mail me first to check
whether this is really a bug, or a feature, or the third
possibility that you simply didn't understand some of FAS's
details.

BTW, here are the lines that are responsible to raise DTR on the
first open of a port:

>	    fip->mcr |= (fip->o_state & OS_WAIT_OPEN)
>			    ? fip->modem.m.ei
>			    : fip->modem.m.eo;

>So the system is partially working at the moment.  However, doing
>an ioctl with B0 set still doesn't hang up the port.  Here is what
>the relevant section of far_param looks like:
>
> [stuff deleted]
>
>Without the signal() call an stty 0 would drop DTR and the line
>would hang up.  Good so far.  However, the processes on this line
>didn't receive a HUP signal (or at least, they didn't seem to) and
>just sat there waiting for the device to send some more input.  So
>I added the signal() call.  This caused my system to stop running
>things, though the device drivers were still going (input still
>echoed, and the like).

You make the false assumption that the dropping of DTR sends the
SIGHUP signal to the process group. If you configure FAS the
right way (as it is by default), a DTR drop will hang up the
modem, which in turn drops DCD, and this drop sends SIGHUP, at
least as long as you haven't disabled that via the termio
structure, or by chosing a minor device # that disables DCD
detection.

      Uwe
-- 
Uwe Doering  |  INET : gemini at geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini