From owner-freebsd-current Mon Oct 8 21:34:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E944737B403 for ; Mon, 8 Oct 2001 21:34:37 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA11444; Tue, 9 Oct 2001 14:34:23 +1000 Date: Tue, 9 Oct 2001 14:33:39 +1000 (EST) From: Bruce Evans X-X-Sender: To: Terry Lambert Cc: Dmitry Karasik , Subject: Re: /dev/cuaa broken ? In-Reply-To: <3BC1E8C0.2C409E3C@mindspring.com> Message-ID: <20011009140811.M22446-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 8 Oct 2001, Terry Lambert wrote: > Bruce Evans wrote: > > I haven't found the bug yet. It was first fixed relatively recently > > in rev.1.152 (1996/11/30) of sio.c. Until then, you had to have waits > > in your program or dtrwait large enough to avoid loss of data on close. > > But dtrwait didn't help for the ioctls that need to wait for output to > > drain. > > Shouldn't he just disable the FIFO for this usage? Disabling the input fifo might have help a bit, but not completely because there is still a "FIFO" of length 1 for the last byte, not to mention the 10 msec deep pseudo-DMA input fifo and the much larger tty input queues. With the default quantum of 100 msec, a single cpu hpg process could easily delay reading of the data for 100 / 0.96 = 104 character times at 9600 bps, so 104 characters could easily be flushed from the input queues alone when carrier loss is detected by the receiver. Flushing input on carrier loss is clearly wrong, but BSD has done it since at least Net/2. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message