Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: cgd serial driver says "silo overflow"
Message-ID: <1993Mar9.212152.10720@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <RALF.93Mar2022955@isidor.en.open.de>
Date: Tue, 9 Mar 93 21:21:52 GMT
Lines: 59
In article <RALF.93Mar2022955@isidor.en.open.de> ralf@reswi.en.open.de (& E. Stranzenbach) writes:
>Hi,
>
>i've connected a terminal to my 386bsd pc using cgd's serial driver.
>As far as i see, the driver works ok. most of the time. But there are
>still some weak points in the driver.
>
> o Everytime, when i switch my terminal off, the driver says
> "silo overflow". This looks very funny becaus the line is at
> 9600 bps only.
You are running his most recent patches, a full 9 pins on the cable and
have HUPCL set and CLOCAL unset? Otherwise, on-to-off transition of DCD
(DTR) when the terminal is powered off will not be recognized.
> o I'm used to push the "BREAK" key if my apps (emacs) get stuck
> for any reason. But unfortunately the driver seems not to
> support the break-condition, say: sometimes the driver
> freezes.
What do you want BREAK to do? Generally, BREAK is only recognized by the
getty for baud-rate-switching. If you are trying to use it for space
disconnect as if you were using an old Bell-103 device, don't expect it to
work.
> o If i'm telneting into my *real* computer (NeXT), sometimes the
> output gets garbeled. This *may* be a problem in the
> networking stuff, but, as far as i see, this problem does not
> occur when i'm using the "console".
It's a problem with the networking stuff -- on the NeXT. You can see the
same thing when telnetting into one from a SunOS machine. The problem is
that the telnet does not correctly negotiate 4.2 vs. 4.3 OOB channel flow
control *and* does not flush it's socket buffers on writes.
Get around the problem by recompiling the Net/2 (or 386BSD) telnetd on
your next machine. You may have to add ioctl()'s follwing writes to
flush the data to the client.
This is a general problem with all NeXTStep networking utilities, and
telnetting *from* a NeXT *to* a Sun will result in "weird" flushing.
Recompiling telnet fixes this. The rlogin, rlogind, ftp, and ftpd
utilities all have the same problem.
The option negotiation is incorrect, not inconsistant, so telnettting to
a NeXT from a NeXT works OK.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------