From owner-freebsd-current  Thu Mar  6 23:06:37 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id XAA21276
          for current-outgoing; Thu, 6 Mar 1997 23:06:37 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA21268;
          Thu, 6 Mar 1997 23:06:33 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id SAA04952; Fri, 7 Mar 1997 18:02:05 +1100
Date: Fri, 7 Mar 1997 18:02:05 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703070702.SAA04952@godzilla.zeta.org.au>
To: bugs@freebsd.org, swallace@ece.uci.edu
Subject: Re: serial driver
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>I have noticed a problem with the sio driver.
>
>When receiving data, it goes into a buffer until it is read by read(), right?

Or until it is flushed.  All input is usually flushed when carrier drops.
This has nothing to do with sio.  The upper half of the tty driver does
it for all ttys.  Details: if CLOCAL is set, then changes in the carrier
state are mostly ignored.  Otherwise, when carrier drops:

1) all input is flushed (seems to be a BSD feature, but on a SYSVish
   system you would probably get EINTR for the current read(), if any,
   and then the POSIX behaviour in (3) applies).
2) if the tty has a session leader, then a SIGHUP is sent to the process
   group of the session leader (POSIX standard).
3) subsequent read()s on the tty return 0 or -1 (POSIX standard).  Under
   FreeBSD, this also applies to the current read() because of (1).

>Well, I am losing data because after DTR is dropped, up to 16 bytes sent
>BEFORE DTR are lost or destroyed, so read() is not picking this up.

Dropping DTR only has an indirect affect on read().  It may cause carrier
to drop.

>Even though DTR is dropped, that does not mean all data received in any
>buffer is not valid at this point, but only data received AFTER.
>So even if a read() call is actually called after DTR is dropped,
>it should still return any remaining bytes.

Nope.

>Note:  As a result, up to 16 bytes can be lost.  I have a 16550A chip
>so the driver might not be reading remaining bytes in its buffer.
>I am using 2.2R.

There used to be problems sending the last 16 bytes in the !O_NONBLOCK
case and not sending the last 16 bytes in some other cases.  In 2.1.x,
the port was closed without waiting for the last 16 bytes to be sent.
This caused a premature hangup in the !O_NONBLOCK case.  In 2.1.x and
in 2.2, flushing of output does not affect the 16550 fifos.  This causes
up to 16 too many bytes to be sent in some cases.  In -current, output
flushing does not work if COM_ESP is configured and the port is an ESP.

Your problems might be caused by a 2.1.x sender.

Bruce