Date: Mon, 08 Oct 2001 11:04:20 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: Dmitry Karasik <dmitry@karasik.eu.org>, freebsd-current@FreeBSD.ORG Subject: Re: /dev/cuaa broken ? Message-ID: <3BC1EAA4.DE4F914F@mindspring.com> References: <20011008194257.B16343-100000@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > 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. He's using perl, which is slow. So by the time he gets around to writing another byte, the FIFO timeout has been fired, so he's writing a byte at a time. I think the UART tries to bunch up "bursty" data, on the theory that it might be triggering a line turnaround on a link that needs it, so it wants to gather the write. This means that it will treat one byte and n bytes (n>1) differentially. > 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. He could simply nanosleep before the close... > 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. Yep; I don't know if perl exposes nanosleep, so this may have to be a second. That's ugly. > - the zombie state probably shouldn't affect returning previously received > input to userland. I remember that the mouse line discipline used to disable the FIFO... is there any chance he could disable the FIFO? He dosn't need it to be fast, or he wouldn't be using perl, he'd be using a compiled language instead. -- Terry 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?3BC1EAA4.DE4F914F>