Xref: utzoo comp.unix.internals:3036 comp.unix.xenix.sco:2810 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!math.fu-berlin.de!fub!geminix.in-berlin.de!gemini From: gemini@geminix.in-berlin.de (Uwe Doering) Newsgroups: comp.unix.internals,comp.unix.xenix.sco Subject: Re: DTR and the FAS serial driver Message-ID: Date: 15 Jun 91 20:38:12 GMT References: <1991Jun11.044804.7690@cynic.wimsey.bc.ca> Organization: Private UNIX Site Lines: 90 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