From owner-freebsd-hackers Sun Aug 3 16:42:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA26465 for hackers-outgoing; Sun, 3 Aug 1997 16:42:19 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA26460 for ; Sun, 3 Aug 1997 16:42:16 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id JAA15646; Mon, 4 Aug 1997 09:12:03 +0930 (CST) From: Michael Smith Message-Id: <199708032342.JAA15646@genesis.atrad.adelaide.edu.au> Subject: Re: tty-level buffer overflows In-Reply-To: <19970803112147.21483@crh.cl.msu.edu> from Charles Henrich at "Aug 3, 97 11:21:47 am" To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Mon, 4 Aug 1997 09:12:03 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, tom@sdf.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Henrich stands accused of saying: > > > > Not in this case, its a 16550A, on a 486/66 doing absolutely nothing > > > except trying to do filetransfer over the serial port with a custom app I > > > wrote.. > > > > And of course if you bothered to read the sio(4) manpage it would tell you > > what the error message means. Or if you'd mentioned that you're using a > > Ooh, arent we high and mighty. I did read the man page, one line that says > "The application is broken" is about as useless as it gets. As my original Actually, the manpage says : sio%d: tty-level buffer overflow. Problem in the application. Input has arrived faster than the given module could process it and some has been lost. I don't know how your problem could be more succinctly described. > > Your application is busted; data is arriving faster than your app is reading > > it, and the kernel has run out of patience and started throwing the data > > away. > > Im afraid not, the application is a software Upload, with a singly byte ack > every 2k, if the serial port cant handle that, theres a problem. I would > presume that if the buffer is full, a write() should block. ... you haven't read the manpage then. It is the receiving side of your application that is at fault, not the transmitting side. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[