life after death (of uport)

[Vernon Schryver]

In article <1989Aug10.230329.24196 at robohack.uucp>, woods at robohack.uucp (Greg A. Woods) writes:
> ...
> First off, you do not say which version of ISC 386/ix you are working
> with.  The one described as being good is from 2.02....
> 						Greg A. Woods
> woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET}
> +1-416-443-1734 [h]	+1-416-595-5425 [w]	Toronto, Ontario;  CANADA

Ahem.  In the original article in this string, I meant to say that the ISC
2.0.2 asy driver is far better than the Microport 3.0e asy driver, in the
sense of "less bad" rather than absolutely "good."

I've observed some serious difficulties.  First, the 2.0.2 driver
frequently looses characters on this Everex Step/20 with a TB+ at 19.2
on a card with 61550A's.  I have not hacked the code to get the UART status
to prove that overruns are happening (no source, of course), but watching
the results of `uucico -x9` and listening to the speaker convinced me.  Jim
Murray's driver also looses characters, tho much less often.  My result is
a loss of UUCP performance from 1400 for uport to 1100 with ISC, both with
Jim's driver.  I suspect the ISC version is not turning on the FIFO.  There
is a reference to "16550" somewhere in the conf. files or documents, but
ISC techincal support knows nothing about it.  A moment's thought about now
many serial cards come with 16550A's instead of 16450's offers a clue.  I
am concerned that this (presumed) overrun problem shows terrible interrupt
latency elsewhere in the kernel, which will be difficult to find, tho
perhaps easy to fix.

Second, the 2.0.2 driver is said by ISC technical support to not support
the industry practice RTS/CTS flow control.  (It's not "standard" as in
RS-{232C,422,...}, but it is a de facto standard.)

The 2.0.2 asy driver does not correctly understand DCD.  If you try `cu -d`,
you'll notice that SVR3.2 cu(1) and UUCP like to open the device with and
later turn off NDELAY.  The 2.0.2 driver seems to understand NDELAY to mean
(1) "open even if DCD is false, and die if ever NDELAY and DCD are both
false", instead of (2) "open even if DCD is false, and do not pay attention
to DCD until DCD has been true."   Whatever, the result is that cu(1)
looses the port as soon as it turns off NDELAY.  You'll notice that this
use of NDELAY differs from the Microport scheme of relying only on minor
device numbers, and the Sun use of CLOCAL.  Code of mine using NDELAY as
(2) above in another universe coexists successfully with uugetty, HDB UUCP,
cu, SLIP, et al, so I think it's a good idea.  The only work-around I could
discover before abandoning ISC's driver was to wire DCD permanently true.
You might try the SVR3.[01] cu and uucico.  This may be needed only on an
out going line.

The ISC 2.0.2 use of NDELAY seems to apply not only to ttyd[01], but also
to tty0[01], which seems like another bug.

I've been told Jim Murray's driver "will not work", and I must admit that
while it works for me, I do not use COM ports in VP/ix.  I've also heard
that ISC is testing an improved driver, but I do not know if these specific
problems have been fixed.

Vernon Schryver
vjs at calcite.uucp   or    {sgi,pyramid}!calcite!vjs