bruce@blilly.UUCP (Bruce Lilly) (01/06/91)
There is apparently some undocumented interaction between hardware and software flow control on the 3B1. First some background: The tty driver permits software flow control for the input queue, so that when the input queue is ``nearly'' (undocumented) full, a CSTOP (control S) will be output, and when the queue is nearly empty a CSTART (control Q) is sent. This is controlled (supposed to be) by the IXOFF bit in the c_iflag int in the termio structure. Refer to the termio(7) man page for more details. The 3B1, at least in 3.51 and later OS versions, also has a program, /etc/hfc_ctl, which can turn hardware (RTS/CTS) flow control on or off for a port. The problem: What is not mentioned in the manual pages is that if hardware flow control is turned on for a port, software flow control doesn't work -- the IXOFF bit is effectively ignored. There also doesn't appear to be any (documented) way to determine whether hardware flow control has been turned on, or is off, for any given port. The return value (exit status) from /etc/hfc_ctl certainly isn't of any use in this regard. This means that if a program needs software flow control (e.g. a communications program which needs to suspend output from a remote computer), one ought to run /etc/hfc_ctl to turn off flow control for the port being used (in case it had been turned on). Because there's no way to know whether flow control was on or off, there's no way to restore the previous state. Therefore, any program which needs hardware flow control, also should run /etc/hfc_ctl to turn it on. Arghh... If anybody knows of a way for a program to determine the state of hardware flow control, I'd like to hear about it. Note: running strings on /etc/hfc_ctl reveals that it apparently uses a TCHFCCTL (undocumented) ioctl. -- Bruce Lilly blilly!bruce@Broadcast.Sony.COM ...uunet!sonyusa!sonyd1!blilly!bruce