X5 Update - Serial Bugs

John G. De Armond jgd at rsiatl.UUCP
Wed Oct 11 06:47:03 AEST 1989


In article <[2531618a:210]comp.unix.i386 at tronsbox.UUCP> tron1 at tronsbox.UUCP (HIM) writes:
>
>
>Well, I am about ready to give up on ISC 2.0.2 . 
>

This would be funny if we had gotten this trash public domain. (No smileys).

>If there is anyone who has managed to get a GOOD asy device running from any
>source, I could really use the help.

NO!!!! but I have a workaround.  My current configuration is 2.0.2 with
the x5 upgrade.  You need that upgrade for what follows.

As delivered, the system is incapable of keeping up with a 9600 baud
Telebit line, something my XT turbo machines will do with ease!!
I tried the pd asy driver mentioned here in the group but it is flakey,
hanging on ioctl calls and is generally unstable.  I do plan to work
on that a bit in the future.

You MUST install 16550 uarts in order to run over 4800 baud on a
non-cached machine.  Mine is a 20 mhz non-cached, no wait state machine.
With the 16550s installed and the X5 upgrade, speed is no problem. It 
easily handles the telebit even with a couple of compiles going
in the foreground.


>Our saga so far.
>
>1) The origional ISC 2.0.x driver.....
>    Well. It doesnt REALLY work well. Many mysterious happenings. 
>    Problems with port sharing. Character loss problems.

Yes, biggest problem is spurrious signals.

>3) The Interactive Systems X5 "Asy Update".
>      I'll spare you the pain. It hasn't worked so far. It installs, but wont
>   perform right . Getty's hang and won't "kill -9". Ports will drop
>   characters at will.

It still generates spurrious signals, just not so many.  uugetty is brain-dead.
One note, if you try to make uugetty run, be sure and use the one in 
/usr/lib/uucp, NOT the one in /etc.  The /etc/getty is totally broken.

Other problems you have not mentioned.  uugetty does not respect lock files.
I've seen it get in such a nice conversation with another login that
it locks all keyboard input, which means Big Red Switch time.

There are a couple of things you can do to make uugetty at least run.
in /etc/gettydefs, place the statements CLOCAL and BRKINT in the first
stanza and BRKINT in the second.  CLOCAL will make the modem-controled
device (minor device 1) work somewhat properly.  BRKINT makes the DTR
line drop after the last process dies (sometimes, at least).
Also, be sure and turn CLOCAL on during modem chatting and back off 
after connection is established.  This involves the \M and \m (off and 
on respectively) in Dialers.  And be sure to use the "tty01,M" notation
in Devices.

A workaround I came up with for the failure to observe lock files (don't
gag now) got me by while I worked on the uutty replacement.  What I did
was write a script that encapsulates uucico.  It copies an /etc/inittab
in place that turns the getty off, then it kills the getty.  Finally,
it runs the uucico binary.  When uucico exits, it replaces the /etc/inittab
and respawns the gettys.  Since uusched expects to run a binary, I had to
write a 3 line c program that exec's a shell and runs the script.  Yes, it's
grody but it works.

I solved the problems the old fashioned way - I wrote my own uugetty.  I 
based it in the pd uutty written by John Chambers.  The version I got was 
written to control some strange VME smart card via a firmware debugger.  
And it was broken.  I've rewritten most of it but am not yet finished.  
Among the things it does are the following:

Traps ALL signals.  Sig 9 is of course, fatal so the process can be killed.

Generates an activity log and records all spurrious signals

Ignores /etc/gettydefs. Too much trouble.

Takes an intelligent look at data comming in to figure out if it
	is in conversation with another login.  IF so, it shuts up until
	prodded by a single <CR> on a line.

Waits for a <CR> to fire a login: prompt.

Respects lock files (!!!!!!!)

Creates a proper lock file for uucico.

Exits properly when the line hangs up and toggles DTR which is necessary
	to force the telebit to reload default params.

Works with either a blocking or non-blocking asy driver. (!!!)
Is fairly small.

Aborts the login process if it receives any illegal login name characters.
A ":" would probably mean that it was chatting with another login.  Other
spurrious characters could mean line noise or hackers.


Major problems at this point:

Ioctl parameters are hard-coded.  They may stay this way as it is as easy
	for me to change defines in a .h file as it is to get /etc/gettydefs
	right.

A password is required.  I don't personally like passwords on uucp accounts
	so this is a priority.

Debugging log is cryptic at best.  Much work to be done here.

I plan on posting this work to the net when I get it finished.  PLEASE don't
hit me with a bunch of requests for the work in progress.  It may take me
a week to finish, if the %&^%^& system will stay up long enough.
The work-arounds above got me by while I was working on this problem.

Boy, I hope one day that Interactive will get it together.  It would be
nice to offer this stuff to customers with some hope it would work.
As it is, OS/2 is looking (ahem) better every day.  (now I'll go wash
my mouth out!).

John

>SO IF ANYONE HAS A WORKING ASY DRIVER -- HELP!!! 
>

I am going to get back to work on the pd ASY driver as soon as I get time.

John


-- 
John De Armond, WD4OQC                     | Manual? ... What manual ?!? 
Radiation Systems, Inc.     Atlanta, GA    | This is Unix, My son, You 
gatech!stiatl!rsiatl!jgd  **I am the NRA** | just GOTTA Know!!! 



More information about the Comp.unix.i386 mailing list