Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Aug 1997 10:53:33 -0400
From:      Charles Henrich <henrich@crh.cl.msu.edu>
To:        "Louis A. Mamakos" <louie@TransSys.COM>
Cc:        Nate Williams <nate@mt.sri.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: tty-level buffer overflows
Message-ID:  <19970804105333.36921@crh.cl.msu.edu>
In-Reply-To: <199708040511.BAA23487@whizzo.TransSys.COM>; from Louis A. Mamakos on Mon, Aug 04, 1997 at 01:11:36AM -0400
References:  <19970803025730.57257@crh.cl.msu.edu> <199708030852.SAA13473@genesis.atrad.adelaide.edu.au> <19970803112147.21483@crh.cl.msu.edu> <199708040423.WAA26367@rocky.mt.sri.com> <199708040511.BAA23487@whizzo.TransSys.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
On the subject of Re: tty-level buffer overflows, Louis A. Mamakos stated:

> No, I think that Charles is surprised that he's *sending* 2K blocks, and
> getting error messages described on the single byte ACK characters which is
> being *received*.
> 
> Could it be that there is cross-talk, and some of the data being transmitted
> is being "heard" as input?

The first paragraph is exactly what I was thinking.  Okay, I finally found
this out.  This remote hardware device (I have no control over the software on
it) has a problem.  After every packet sent, the device must be entering some
critical section, because it doesnt pay attention to its serial ports for
30-50ms.  So what was happening is during a packet send, if the write was
still occuring during that critical section, a few packets would be lost and
the remote end would get confused, abort back to terminal mode, and spew back
what I was writing.  This only caused a problem if it occured early into my
write(), otherwise my app exited and read back the crap fast enough to not get
the tty error.  With the usleep() in the proper place everything is working
peachy keen.  Thanks to all for your assistance!  

I might suggest in sio(4) we say something like:

     sio%d: tty-level buffer overflow.  Problem in the application.  Input has
     overflowed inbound buffers, data has been lost.  This problem commonly
     occurs when the application does not perform a read() often enough to
     empty the incoming buffers before more data arrives.

-Crh

       Charles Henrich     Michigan State University     henrich@msu.edu

                         http://pilot.msu.edu/~henrich



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970804105333.36921>