Date: Fri, 7 Mar 1997 18:02:05 +1100 From: Bruce Evans <bde@zeta.org.au> To: bugs@freebsd.org, swallace@ece.uci.edu Cc: current@freebsd.org Subject: Re: serial driver Message-ID: <199703070702.SAA04952@godzilla.zeta.org.au>
next 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? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703070702.SAA04952>