Date: Fri, 27 Jun 1997 08:06:00 -0400 From: "Brian J. McGovern" <mcgovern@spoon.beta.com> To: bde@zeta.org.au Cc: hackers@freebsd.org Subject: Re: XON/XOFF intrusion Message-ID: <199706271206.IAA16904@spoon.beta.com>
next in thread | raw e-mail | index | archive | help
>>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 agree completely. But take a look below... >>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. > Nope. I have IX* printfs right in the interrupt handler. If it gets turned on, it'd have to get turned right back off again. The one routine that does do the setting of flow control has the values &= ~(...)'ed right before the hardware is set. Chances of it floating on elsewhere - slim to none (tho I won't say its 0) >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. > Sounds about right. The device I'm playing with has 8K of onboard receive buffer. I'm using hardware-induced RTS/CTS signaling. The line disc. should never have to eat more characters than it wants at any given time. However, I did note one interesting thing in tty.c (/usr/src/sys/kern), starting on line 318 (version 2.2.1). Its the if statement that decides if ttyblock() gets called. I did some reduction of the expression, and got (in pseudo-code): if ( (tp clists > 512) && (!ICANON || tp->t_canq.c_cc != 0) && (CRTS_IFLOW || IXOFF) && !TS_BLOCK) I'd buy most of that as being reasonable, except the CRTS_IFLOW portion. Why would I want to introduce Xon/Xoff handling if I have CRTS_FLOW? Especially when this flag represents half of hardware flow control? I think it should be !CRTS_IFLOW. Or, more appropriately, it should be removed from the expression so that hardware and XON/XOFF flow control can be used at the same time if so desired (tho I can't see a rational as to why you'd really want to do that). Am I wrong? Am I missing something? Please, set me right. :) -Brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706271206.IAA16904>