From owner-freebsd-bugs  Fri Mar  7 09:52:05 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA03023
          for bugs-outgoing; Fri, 7 Mar 1997 09:52:05 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02951;
          Fri, 7 Mar 1997 09:51:59 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA16968; Fri, 7 Mar 1997 10:45:14 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199703071745.KAA16968@phaeton.artisoft.com>
Subject: Re: serial driver
To: swallace@ece.uci.edu (Steven Wallace)
Date: Fri, 7 Mar 1997 10:45:14 -0700 (MST)
Cc: bugs@freebsd.org, current@freebsd.org
In-Reply-To: <199703070548.VAA20665@newport.ece.uci.edu> from "Steven Wallace" at Mar 6, 97 09:48:09 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-bugs@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?
> 
> 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.
> 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.
> 
> 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.

DTR is dropped when the last open reference to the port is closed.

I believe you are confusing DTR drop with DCD drop???



Is this data in the kernel receive buffer, or in the chip FIFO?

If it is in the chip FIFO, it is the fault of the chip notifying us
of the DCD loss before it notifies us of the data availability, since
we can not tell the difference between data in the chip FIFO that was
placed there *before* it sent the on-to-off DCD transition signal,
and data which was placed in the FIFO buffer *after* it sent the
on-to-off DCD signal, but *before* we completed processing the signal.
...Maybe a long time after, given the priority of serial interrupts
relative to minor things like disk, network, and DRAM refresh.  We
can't, under any circumstances, legally use the data after the DCD
loss.  Ever.  It could be disconnect noise for all we know.

The problem is that the chip should signal the available data *before*
it signals the DCD drop, and it should wait to signal the DCD drop
until we have processed the available data.

But the chip does not place a DCD loss marker in its own FIFO so that
it can do this reliably.


If it is data in the kernel receive buffer, than this is a bug... we
should flush the inbound characters before propagating the DCD loss
so as to maintain strict event ordering.


Are you sure you are using one of the good UARTs?  The majority of
UARTs are not good.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.