From owner-freebsd-hackers Mon Aug 4 07:54:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA04154 for hackers-outgoing; Mon, 4 Aug 1997 07:54:03 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA04137 for ; Mon, 4 Aug 1997 07:53:48 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id KAA15402; Mon, 4 Aug 1997 10:53:34 -0400 (EDT) Message-ID: <19970804105333.36921@crh.cl.msu.edu> Date: Mon, 4 Aug 1997 10:53:33 -0400 From: Charles Henrich To: "Louis A. Mamakos" Cc: Nate Williams , freebsd-hackers@FreeBSD.ORG Subject: Re: tty-level buffer overflows 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.80 In-Reply-To: <199708040511.BAA23487@whizzo.TransSys.COM>; from Louis A. Mamakos on Mon, Aug 04, 1997 at 01:11:36AM -0400 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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