From owner-freebsd-current Fri May 12 04:30:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA27402 for current-outgoing; Fri, 12 May 1995 04:30:19 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA27381 for ; Fri, 12 May 1995 04:29:53 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA23896; Fri, 12 May 1995 21:25:27 +1000 Date: Fri, 12 May 1995 21:25:27 +1000 From: Bruce Evans Message-Id: <199505121125.VAA23896@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.org, uhclem%nemesis@fw.ast.com Subject: Re: Taylor UUCP and flow control Sender: current-owner@FreeBSD.org Precedence: bulk >[0]The correct setting is system dependent. That's why everything in rc.serial >[0]is commented out by default. The setting of dtrwait is safe enough but >[0]the setting of crtscts may cause problems if the modem doesn't assert CTS >[0]except when there is carrier. >That reminds me. Taylor UUCP 1.04 and 1.05 both deliberatly disable >hardware flow control (-crtscts) when it is running. You have to change >the UUCP source (as far as I know) to get hardware flow control to remain >on. This happens for incoming and outgoing UUCP sessions. I think uucp has an option to set crtscts. It certainly has some ifdefs involving it. The lock bits in ttyid* are meant for handling this problem in applications that don't support crtscts properly. You can set the crtscts bits in ttyid* to lock the initial value of crtscts and the crtscts bits in ttyld* to set the initial value to on. This is done in the modem() example in /etc/rc.serial. The problems occur when you set or lock crtscts for a device that doesn't support it, e.g., if crtscts is locked on on a mouse port, then X will hang forever waiting for CTS. Bruce