RTS-CTS bad on ttyf??

Vernon Schryver vjs at rhyolite.wpd.sgi.COM
Sat Sep 8 03:50:41 AEST 1990


> From @CUNYVM.CUNY.EDU:karron at mcirps2.med.nyu.edu  Thu Sep  6 20:04:44 1990
>...
> WRONG ! . These ports should open, but no characters should move until
> CTS is engaged. I don't know about newer machines, but the CTS pin
> seems to be GROUNDED, as I can't get the breakout box led to light
> up when it is connected to +BATTERY, or low when -BATTERY.

You appear to have a bad cable somewhere.  CTS is not grounded in old
or new machines.  The fault could be either your external cable or
something within the machine.

>...
> I am also finding that the kermit I use does a core dump on trying
> to open ttyf[1,2] with handshake engages. After a while, I am getting
> messages about streams being out of resourses. I will reboot the
> machine to clear the streams kernel, but this does not look good.

You apparently have your own kermit.  The core dump might tell you what
it is doing.

Running out of streams resources is most often caused by echo-loops
between the machine and a modem.  For example, if you configure your modem,
printer, or whatever with echoing turned on, and then turn on a getty at
high speed, you can cause shouting matches that consume vast numbers of
buffers.

> The /dev/tty{d,m}4 (I only tested 4, and don't want to spend
> more time on this) do NOT do RTS-CTS, as expected. the /dev/tty{f}4 lines
> does asssert RTS, and drops it as its buffer fills. It does NOT
> listen to CTS. Indeed, I think that that line is shorted someplace
> judging from the behavior of the break out box LEDs'.

This is how the drivers have worked since I added RTS/CTS flow control
years ago.  tty{d,m}* keep RTS=DTR and CTS is ignored.  Only ttyf* do 
hardware flow control, using RTS and CTS as stop and go indications.

> I can use RTS-CTS between the host and the peripheral device.  The host can
> tell the peripheral to stop transmitting, but the peripheral can not tell the
> host to be quiet.  For my application (verbose peripheral limited by host),
> that is fine.  However, since I can't get a signal from the hosts CTS,
> loopback testing of the host RTS-CTS does NOT work.  Indeed, my experience
> with RTS-CTS signaling is that the host should not transmit unless CTS is held
> high.  It seems that sgi does not respect CTS, and holds RTS up except when it
> does not want characters.  The tty{m}4 properties seem to work as expected.
> The machine would send a HANGUP (or at least kermit said somthing) signal when
> DCD was disconnected.
>....

Again, it sounds as if you have a bad cable.

RTS/CTS flow control not only works well on 4D70's, it is necessary for
another pet of mine, SLIP over >=9.6 modems such as Telebits.



Vernon Schryver
vjs at sgi.com



More information about the Comp.sys.sgi mailing list