curt@cynic.wimsey.bc.ca (Curt Sampson) (06/11/91)
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.
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):
setmcr:
/* set up modem and flow control lines */
fip->mcr &= ~(fip->modem.m.di
| fip->modem.m.ei
| fip->modem.m.eo
| fip->flow.m.ic
| fip->flow.m.hc);
fip->mcr |= (fip->o_state & OS_WAIT_OPEN)
? fip->modem.m.ei
: fip->modem.m.eo;
if (fip->o_state & OS_HWI_HANDSHAKE)
fip->mcr |= fip->flow.m.ic;
else if (!(fip->o_state & OS_HDX_HANDSHAKE))
{
fip->flow_flags.s |= FF_HDX_STARTED;
fip->mcr |= fip->flow.m.hc;
}
/*
* 91.06.09 -- turn on DTR on open, too! -- cjs
*/
fip->mcr |= MC_SET_DTR;
fas_outb (fip, MDM_CTL_PORT, fip->mcr);
fip->device_flags.s |= DF_DEVICE_OPEN | DF_MODEM_ENABLED;
}
Basically what I did was add the fip->mcr |= MC_SET_DTR; line before
it outputs the final modem control register byte. This works fine
so far, turning on the DTR when the port is opened. Because the
MCR byte gets masked when the port is closed, DTR is dropped
correctly on the last close of the port.
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:
/* hangup line if it is baud rate 0, else enable line */
if ((cflag & CBAUD) == B0)
{
fip->mcr &= (fip->o_state & OS_WAIT_OPEN)
? ~fip->modem.m.ei
: ~fip->modem.m.eo;
/*
* 91.06.09 -- to hang up, turn of DTR, wait 1/2 second,
* and turn it back on again. Also send hangup signal
* to all processes that have this tty open. -- cjs
fip->mcr &= ~MC_SET_DTR;
fas_outb (fip, MDM_CTL_PORT, fip->mcr);
delay(HZ/2);
fip->mcr |= MC_SET_DTR; /**/
fas_first_outb (fip, MDM_CTL_PORT, fip->mcr);
fip->device_flags.s &= ~DF_MODEM_ENABLED;
/* (void) signal (fip->tty->t_pgrp, SIGHUP); /* -- cjs */
}
else
{
if (!(fip->device_flags.i & DF_MODEM_ENABLED))
{
fip->mcr |= (fip->o_state & OS_WAIT_OPEN)
? fip->modem.m.ei
: fip->modem.m.eo;
fas_first_outb (fip, MDM_CTL_PORT, fip->mcr);
fip->device_flags.s |= DF_MODEM_ENABLED;
}
}
My modifications have been commented out, as they locked up the
system after an stty 0. :-) I added the four lines after the
comment and the one after the output that has a comment as well.
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).
I'd appreciate any clues as to what's going on here. Have I set
up FAS wrong in some way? It seems very strange that it woudn't
assert DTR, but I couldn't find anything to make it do so in the
configuration files. Is there something I can configure? How
about a patch I can apply. Failing that, I'd appreciate any help
on modifiying the device driver to work DTR correctly.
Thanks in advance. This has certainly been a learning experience,
at any rate. :-)
cjs
--
| "This sound system comes to you with fuel injection.
Curt Sampson | Toes tapping, the unthinking masses dance to a new
curt@cynic.uucp | tune. . . . Undress yourself to this bastard. Suck
curt@cynic.wimsey.bc.ca | on this plan of noise, bimbo!" --Gary Clailgemini@geminix.in-berlin.de (Uwe Doering) (06/16/91)
curt@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@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini