NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/att/2822

Text File | 1993-01-06 | 8.4 KB | 171 lines

Newsgroups: comp.sys.att
Path: sparky!uunet!uunet.ca!geac!torag!robohack!woods
From: [e-mail] (Greg A. Woods)
Subject: Re: 3b2 EPORTS device driver bugs
Organization: Elegant Communications Inc.
Summary: no, it's not a config. error, it's a bug!
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 6 Jan 93 06:22:24 GMT
Lines: 159

In article <[e-mail]> [e-mail] (Robert N Thomas) writes:
> In article <[e-mail]> [e-mail] (Greg A. Woods) writes:
> >However, as some of you may recall, I posted a note about a problem
> >which began to plague my Hayes 2400 and Telebit T-1000 some time ago.
> >
> >The symptoms were a hung modem, and on the Hayes, the appearance of
> >RD, SD, TR, and MR being on continuously.
>
>      Ah yes, the olde RD/SD light up forever problem..  Greg, try
> setting setting your modems to power on default to ATE0Q1..  This
> will eliminate the SD/RD light problem..  You also want the modem to
> hang up and RESET when the DTR line drops...

Ah, nope, sorry, wrong answer!  :-)

I've been playing with modems and unix for 10 years now, and know
well the symptoms of the problem you describe.  The problem I've
described has absolutely nothing to to with it.

Indeed I was not so foolish as to not intentionally create the
problem you describe in order to measure its effect and record
its actual symptoms (I'd grown quite accustomed to making it work
right the first time, and had never seen this problem occur on a
3b2 with an EPORTS card until then).  Most notably it causes
system load to increase sharply, due to the getty (i.e. uugetty)
responding to the messages from the modem in an endless loop.
Well, it's only endless until uugetty times out, assuming you've
had the foresight to set the timer ("-t n")!  In fact the load on
the EPORTS card itself will increase enough to make itself felt on
other ports, esp. if the modem is a high-speed one!  Finally, note
that I stated there is no continuous RD/SD activity observable on
the Telebit -- this has only happened on Hayes, USR, Microcom, and
various 2400 and 1200 bps clones, and I repeat that it causes no
system or interface card load increase.

Indeed my modems do not normally return result codes for incoming
calls, and given that the EPORTS drivers do correctly drop DTR at
the end of every call, even if a new uugetty is ready to open the
port, and thus the modems will reset from the "ATE1Q0" issued in
the dialer script (since I've configured them to do so).

Not only that, but you might also note I stated that the *only*
resolution was to either re-pump the firmware, or to cycle the
power on the modem.  NOTHING else works.  Period.  Not killing
getty's.  Not pulling out the RS-232.  Not pulling the RS-232 and
then cycling the power.  Not trying to open the port, hang it up,
change the hardware flow control (even though it's not used on
one of the modems), change any other termio setting, nor even
read or write to/from the port.

The reason I truly wish to observe the events on a protocol
analyser is to record the timing of various control signals, and
to record what is generating what appears to be continuous RD/SD
activity, and to record these signals while the power is cycled
on the modem.

So far I've experimented to the limits of the Telebit's amazing
configurability to modify the timing of responses to various
events, but all to no avail.

>     My system does not use \m, because when the modems PULSE the CD line,
> the 3B2 say's DISCONNECTED..

You must not be running the same version of HDB-UUCP (i.e. BNU)
that I'm running.  Or not the same drivers.  Or perhaps not even
the "modem-control" configuration.  If CLOCAL is set, the driver
had damn well better not generate SIGHUP on transition of DCD, or
it can be declared completely broken!  If CLOCAL is set, at the
termination of a call with "cu" (for example) you'll simply see
the "NO CARRIER" from the modem (if it's generating result codes)
and you'll have to disconnect manually with "~.".  Uucico will
disconnect itself, as it will either time out, or will have
received the hangup command from the remote system, or will be
the one issuing the hangup, and subsequently close the port and
exit.

Your ports may have CLOCAL clear initially if you are *not* using
",M" in the Devices file, _and_ *not* using "\M" at the beginning
of the Dialers entry, and thus a "\m" would be redundant anyway.
In this case you'd only be able to dial out if your modems
normally supply DCD (except perhaps for a brief period after loss
of carrier), and this is in fact how you've described your
configuration.

Congratulations on the hardware tricks to make the USR work!
I've avoided these ugly little critters for this very reason!

Also note that my modems seem to function fine when DCD follows
signal carrier (i.e. is not pulsed), though this indeed does
require CLOCAL to be initially cleared (since the first read on a
port without CDC would then generate a SIGHUP, and since cu and
uucico don't ignore it at this point during dialing, you just get
the famous "lost line errno 0" message and a re-try), and thus
seems to induce the problem I've described.

>      I know whatche mean about the hardware flow control hastle..  While
> your at it Santa, could to fix the drivers so the XON/XOFF and HFC can
> both be enabled at the same time???   Would be nice, and thanks..  Well,
> I don't know if that helps you all the much Greg, you have an idea of
> what I do here to get by..

I'm not fussy about enabling XON/XOFF together with HFC
actually.  Given adequate control of the modem, it is sufficient
to enable software flow control in the modems when doing
interactive work, though ideally one would simply disable all
large buffers in the modems, and have hardware flow control at
each DCE<->DTE connection, thus permitting any given form of flow
control to be enabled (eg. the "pause" button when running with
layers).  The only problems with this crop up not when you wish
to have manual data flow control, but rather when you wish to
interrupt data flow completely, such as when you've issued a
command that's spewing output to you, and you want to hit
"INTR".  Even if you can get the BREAK function to properly flush
all the possible buffers along the way, you may not be able to
conveniently generate a BREAK with the key you think of as
"INTR".  What usually results is you press <DEL> or <ctrl-\> and
get another 1 kb to 8 kb dumped on your screen.  Another solution
is to *NOT* lock DTE speed in the modem, then ensure that you
have the "same sized pipe" all the way through, as well as no
hidden reservoirs to spray stuff when they shouldn't.

All I really want is a sticky HFC -- then a simple "epstty shfc"
in /etc/rc2.d/S01eports-hfc would do the trick.  Even IBM's
RS/6000 can do this, though they can't yet get modem control
anywhere near right either....

I can't quite understand why these device driver writer's can't
get it right in the first place!  These drivers are not all that
complicated, and any decent description of the RS-232 standard
gives a full state diagram for the call initiation and
termination phases....  It should be a simple as paint by numbers
-- just follow the lines and you can't go wrong!  Not only that,
but the problem I describe is easy enough to reproduce in less
than a dozen attempts, so should be easy enough to track down
should the detective have the right tools.

Of course the problem I've described may be happening deep
withing the interface between the kernel driver and the firmware,
and from what I can deduce from the header files, this is no
simple thing!

Speaking of that, I find there's a couple of neat things in
<sys/ep_lla.h> which seem to indicate the driver and do some
pretty specific things to the firmware, but it seems there's no
way to tell it to do so via any known ioctl()'s.

Anyone who's interested in my all knowing EPORTS driver twiddler,
and missed getting it before, can get a copy by e-mail...

Now, if I had source for the driver and firmware (and a way to
re-compile the firmware! :-), I'm certain that though I may not
be able to find and fix the problem, I'd at least be able to
implement a solid work-around (eg. a soft reset that wouldn't
drop all the processes on un-related ports!).
--
                        Greg A. Woods

[e-mail], [e-mail]  VE3TCP    UniForum Canada & ECI
[phone] [home] +1 416 362-XRSA [work]    Toronto, Ontario; CANADA