Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!news.ans.net!cmcl2!panix!tls From: tls@panix.com (Thor Lancelot Simon) Subject: Re: cgd serial driver says "silo overflow" Message-ID: <C3pBvD.25G@panix.com> Organization: Panix Public Access Internet & Unix, NYC References: <RALF.93Mar2022955@isidor.en.open.de> <1993Mar9.212152.10720@fcom.cc.utah.edu> Date: Thu, 11 Mar 1993 01:52:24 GMT Lines: 49 In article <1993Mar9.212152.10720@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >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. There's an undocumented option to NeXT's stty which seems to help this. Try "stty -extproc" after telnetting to the NeXT. I have no idea why this helps. I have no idea what this does. I have no idea how I figured this out -- I think I ran strings on NeXT's stty. -- Thor Lancelot Simon tls@panix.COM "I'm guided by the beauty of our weapons." -- Leonard Cohen