From owner-freebsd-current Tue Nov 14 09:06:01 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA22104 for current-outgoing; Tue, 14 Nov 1995 09:06:01 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA22091 for ; Tue, 14 Nov 1995 09:05:53 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id EAA17910; Wed, 15 Nov 1995 04:04:28 +1100 From: michael butler Message-Id: <199511141704.EAA17910@asstdc.scgt.oz.au> Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] To: uhclem%nemesis@fw.ast.com (Frank Durda IV) Date: Wed, 15 Nov 1995 04:04:26 +1100 (EST) Cc: current@freebsd.org In-Reply-To: from "Frank Durda IV" at Nov 14, 95 10:27:00 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1563 Sender: owner-current@freebsd.org Precedence: bulk Frank Durda IV writes: > One of the ISPs is trying to let me borrow his communications monitor > so I can see exactly what they are talking about. They claim it will > show that they drop CTS and the processor has sent as many as 14 additional > characters after CTS was deasserted. If true, it sounds like our > hardware flow control does not "call-back" bytes already in the 16550 FIFO > like it should. You can't anyway .. once loaded with 16 bytes for transmission, the withdrawal of CTS only generates an interrupt. To quote the NS spec for the device "/CTS has no effect on the transmitter". This is quite different to the behaviour of, say, a Z80 SIO or Z8x30 SCC which disable the transmitter after the current character has been shifted out. There is also absolutely no mechanism provided to discover exactly how many characters were transmitted prior to the modem status interrupt. Ordinarily, an interrupt occurs only when the FIFO and shift-register are (completely) empty. > The EIA rules for CTS allow you one more full character plus any partial > character to be transmitted before the data must cease .. Then the 16550 itself is in breach of this spec. and there's nothing anyone can do about it in software other than to feed it one byte at a time (and you really don't want to do that!). If this actually is the problem, then *every* PC-based O/S must display the same failing with these devices, not just FreeBSD. The only other possible issue in this area is the speed with which FreeBSD's driver responds to CTS changes, michael