Date: Mon, 4 Aug 1997 09:27:59 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: brian@awfulhak.org (Brian Somers) Cc: henrich@crh.cl.msu.edu, msmith@atrad.adelaide.edu.au, tom@sdf.com, freebsd-hackers@FreeBSD.ORG Subject: Re: tty-level buffer overflows Message-ID: <199708032357.JAA15941@genesis.atrad.adelaide.edu.au> In-Reply-To: <199708031722.SAA19779@awfulhak.org> from Brian Somers at "Aug 3, 97 06:22:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Somers stands accused of saying: > > > > 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. > > It's not a case of the serial port handling it. As the OS receives > data from the com port, it buffers it 'till your application does a > read(). If your application isn't read()ing as fast as the data is > arriving, the kernel buffers will fill. When they're full, the sio > driver can't do anything with the incoming data, so it doesn't bother > reading the port. When your app eventually read()s, some buffers are > emptied and the kernel goes off and reads the receive buffer of the > UART. It notices that the overflow bit is set, and emmits the sio > overflow message. This is very wrong. There are three overflow error messages, each described in the sio(4) manpage. They are as follows : 'silo overflow' : The interupt handler has taken too long to respond to an interrupt condition from the UART, and in that time the buffer in the UART has overflowed, causing data to be lost. This is typilcally an indication of seral port overload and/or unacceptable interrupt latency. 'interrupt-level buffer overflow' : There is a problem inside the driver; interrupts are handling data, but then next layer up (run off a timeout) is not forwarding data to the tty level. This overflow should only occur in the most extreme conditions of system abuse. 'tty-level buffer overflow' : The application reading from the serial port is ignoring data, and such an amount has arrived that the tty layer is refusing to accept any more. The sio(4) driver always reads the UART. The kernel doesn't "go off and read the receive buffers in the UART" when the calling application performs a read; input and output are push-driven, not pull-driven. The error you are attempting to describe is the 'silo overflow' message, which is not the error that Charles is seeing. If his comms protocol's ACK is "any" character, or the protocol is tolerant of spurious characters around the ACK, then it might be that the other end of his protocol is emitting receive stats intended for user consumption back down the comms link. If the sending send does not select() on the back channel except when expecting an ACK, these might easily result in an overflow. -- ]] 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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708032357.JAA15941>