Date: Mon, 8 Oct 2001 21:13:48 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dmitry Karasik <dmitry@karasik.eu.org> Cc: <freebsd-current@FreeBSD.ORG> Subject: Re: /dev/cuaa broken ? Message-ID: <20011008194257.B16343-100000@delplex.bde.org> In-Reply-To: <uzo72h4o4.fsf@karasik.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Oct 2001, Dmitry Karasik wrote: > Further investigation revealed the following fact, which > might be relevant. If a write of 1 byte is issued, everything > is O.K - contrary to when more than 1 byte is written, there > is a problem. It was noticed first with cu, when I typed > a command from keyboard and copy-pasted it after and received > different results. I can't explain why 1 byte works much better, but the problem (as I understand it) is very timing dependent. Multiples of the receiver fifo trigger level best because the timing is favorable then. > As for now, we have fixed our code in such a fashion > that now it writes commands by 1 byte - but since the > exact problem cause is unknown, be it dtr state or > something else, it might be still a hack, that wouldn't work > in different circumstances, on a faster machine for example. I was confused about DTR. It's carrier drop that is the problem (assuming you are closing the device after each command). dtrwait doesn't affect carrier. Carrier is dropped immediately after the output is drained in close(). Then DTR is held high for dtrwait/100 seconds, and further opens are blocked until then. dtrwait normally doesn't matter much, but should be quite large for safety (the default is 3 seconds). However, if you want send a lot of commands and close the file after each, then you don't want it large. My current understanding of the bug is that it is caused by interrupt handling for the receiver working too well :-). If there were no delays except the ones for the receiver fifo (input is not normally seen unless the fifo is nearly full or 4 character times have elapsed since a byte was received), then the last few bytes for "write(); close();" would always be lost since they would be received concurrently with the carrier drop, and on carrier drop the device goes into "zombie" state in which all reads on it return EOF. In practice there are some delays, so they last few bytes are not always lost. Fixes: - senders should probably wait a bit before closing. - the zombie state probably shouldn't affect returning previously received input to userland. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011008194257.B16343-100000>