Date: Mon, 8 Oct 2001 18:06:33 +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: <20011008163346.C14481-100000@delplex.bde.org> In-Reply-To: <uvghwj512.fsf@karasik.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Oct 2001, Dmitry Karasik wrote: > After upgrade to 3.5 to 4.3-stable we encoutered a problem > with our custom device connected to com-port. The device > accepts command strings and returns strings in response, > but under 4.3 it strangely does not respond to commands > that are longer than 15 bytes ( 16 with \r). > > The device is controlled by a code, which, if stripped to > functional minimum is as such: > > open F, "+< /dev/cuaa0" or die "Cannot:$!\n"; > system "/bin/stty -f /dev/cuaa0 gfmt1:ispeed=19200:ospeed=19200 cstopb"; > print F "123\r"; # <- works under both 3.5 and 4.3 > # print F "1234567890123456\r" # <- doesn't work under 4.3 > print "|$_|\n" while <F>; > close F; This works for me under -current, but it stops working if the while statement is removed and dtrwait is set to 0 (not the default) on /dev/cuaa0. Waiting for output to drain is broken. close() waits for output to drain and then waits another dtrwait/100 seconds before dropping carrier. Problems occur when carrier is dropped while there is still data in the output fifo. The data gets transmitted normally but tends to be discarded by the reciver when it arrives arfter carrier drop. > One more strange effect is, that under cu(1) it works. That makes cu(1) works better because it ignores carrier drop, so it doesn't notice when the sender drops carrier prematurely. > us assume that the programming technique used into our program > is inappropriate - but it seems pretty straightforward and > we are just clueless about what implicit 16-byte buffers > might be involved here. My suspicion is that it's the device driver bug, > but unfortunately we cannot afford tracking the exact commit that caused > the malfunction. The relevant magic number is actually 14 for the size of the input fifo on the receiver. The receiver tends to see input in 14-byte chunks. When it sees carrier drop and is not ignoring carrier drop, it discards any further input. I haven't found the bug yet. It was first fixed relatively recently in rev.1.152 (1996/11/30) of sio.c. Until then, you had to have waits in your program or dtrwait large enough to avoid loss of data on close. But dtrwait didn't help for the ioctls that need to wait for output to drain. 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?20011008163346.C14481-100000>