Date: Fri, 7 Mar 1997 10:45:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: swallace@ece.uci.edu (Steven Wallace) Cc: bugs@freebsd.org, current@freebsd.org Subject: Re: serial driver Message-ID: <199703071745.KAA16968@phaeton.artisoft.com> In-Reply-To: <199703070548.VAA20665@newport.ece.uci.edu> from "Steven Wallace" at Mar 6, 97 09:48:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703071745.KAA16968>