From owner-freebsd-hackers Fri Jun 27 00:36:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA09325 for hackers-outgoing; Fri, 27 Jun 1997 00:36:32 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA09319 for ; Fri, 27 Jun 1997 00:36:28 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA16915; Fri, 27 Jun 1997 17:31:23 +1000 Date: Fri, 27 Jun 1997 17:31:23 +1000 From: Bruce Evans Message-Id: <199706270731.RAA16915@godzilla.zeta.org.au> To: hackers@freebsd.org, mcgovern@spoon.beta.com Subject: Re: XON/XOFF intrusion... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I'm having a problem with a driver where XON and XOFFs are being introduced >to the data stream, even when I have IXON, IXOFF, and IXANY turned off >in c_iflag. This shouldn't happen. Spurious XONs and XOFFs are only introduced into the output data stream when the line discipline is the default (termios) and IXOFF is set, at least by the machine-independent part of the driver. IXON and IXANY have no effect on the output data stream. >I know (through programming and printf()s) that c_iflag has the above >mentioned bits off, and that ((tp->t_rawq + tp->t_canq) < (TTYHOG / 2)). Perhaps IXOFF is actually set and tp->t_rawq + tp->t_canq grows soon after you look at it. I_HIGH_WATER is too small for some devices. Flow control won't work if the device ever buffers more than about 512 bytes of input. TTYHOG is too small for some devices. Flow control can't work if the device ever buffers more than about TTYHOG (= 1024) bytes of input. Drivers should read from the device often enough to reduce the burst length to <= 256. At 115200 bps, this means that they must read from the device at least once every 22.2 msec. In practice this means reading every clock tick. Bruce