Prev: Linking problem using autotool
Next: why do the Muslims bow down to ward the Ka'
From: David Schwartz on 11 Jan 2010 13:41
On Jan 11, 5:12 am, Jef Driesen <jefdrie...(a)hotmail.com.invalid>
wrote:

> I patched the pty_open() function to set tty->low_latency=1. With this
> change, transfers are significant faster, but I also get a number of
> timeout errors in the test:

My understanding (going from memory, and it was weak to begin with)
was that all TTYs associated with fast, modern hardware would have the
low_latency flag set. So it should be on for the whole pty system,
IMO. However, I vaguely remember there being bugs. :(

> $ socat PTY,link=/tmp/ttyS0,raw,echo=0 PTY,link=/tmp/ttyS1,raw,echo=0 &
> $ sx input.bin >>/tmp/ttyS0 </tmp/ttyS0
> Sending input.bin, 4206 blocks: Give your local XMODEM receive command now.
> Xmodem sectors/kbytes sent: 462/57kRetry 0: NAK on sector
> Xmodem sectors/kbytes sent: 545/68kRetry 0: NAK on sector
> Xmodem sectors/kbytes sent: 956/119kRetry 0: NAK on sector
> Xmodem sectors/kbytes sent: 2369/296kRetry 0: NAK on sector
> Xmodem sectors/kbytes sent: 2657/332kRetry 0: NAK on sector
> Retry 0: TIMEOUT 206
> Retry 0: TIMEOUT 335
> Retry 0: TIMEOUT 188
> Retry 0: TIMEOUT 655
> Retry 0: TIMEOUT 975
> Bytes received:  538368   BPS:17089

That's scary. On the bright side, you've found an easy to replicate
test case that demonstrates a bug in the pty layer, I think. :((

DS
From: Jef Driesen on 12 Jan 2010 04:18
On 11/01/2010 19:41, David Schwartz wrote:
> On Jan 11, 5:12 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid>
> wrote:
>
>> I patched the pty_open() function to set tty->low_latency=1. With this
>> change, transfers are significant faster, but I also get a number of
>> timeout errors in the test:
>
> My understanding (going from memory, and it was weak to begin with)
> was that all TTYs associated with fast, modern hardware would have the
> low_latency flag set. So it should be on for the whole pty system,
> IMO. However, I vaguely remember there being bugs. :(

I think my Core 2 Duo still counts as modern hardware, but judging from
the speed improvement, the low_latency flag is not set by default.

>> $ socat PTY,link=/tmp/ttyS0,raw,echo=0 PTY,link=/tmp/ttyS1,raw,echo=0&
>> $ sx input.bin>>/tmp/ttyS0</tmp/ttyS0
>> Sending input.bin, 4206 blocks: Give your local XMODEM receive command now.
>> Xmodem sectors/kbytes sent: 462/57kRetry 0: NAK on sector
>> Xmodem sectors/kbytes sent: 545/68kRetry 0: NAK on sector
>> Xmodem sectors/kbytes sent: 956/119kRetry 0: NAK on sector
>> Xmodem sectors/kbytes sent: 2369/296kRetry 0: NAK on sector
>> Xmodem sectors/kbytes sent: 2657/332kRetry 0: NAK on sector
>> Retry 0: TIMEOUT 206
>> Retry 0: TIMEOUT 335
>> Retry 0: TIMEOUT 188
>> Retry 0: TIMEOUT 655
>> Retry 0: TIMEOUT 975
>> Bytes received: 538368 BPS:17089
>
> That's scary. On the bright side, you've found an easy to replicate
> test case that demonstrates a bug in the pty layer, I think. :((

I think this might be related to this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3

The patch that was reverted in that commit is almost equal to the patch
I applied!
From: Rainer Weikusat on 15 Jan 2010 12:55
Jef Driesen <jefdriesen(a)hotmail.com.invalid> writes:
> On 11/01/2010 19:41, David Schwartz wrote:
>> On Jan 11, 5:12 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid>

[...]

>>> $ socat PTY,link=/tmp/ttyS0,raw,echo=0 PTY,link=/tmp/ttyS1,raw,echo=0&
>>> $ sx input.bin>>/tmp/ttyS0</tmp/ttyS0
>>> Sending input.bin, 4206 blocks: Give your local XMODEM receive command now.
>>> Xmodem sectors/kbytes sent: 462/57kRetry 0: NAK on sector
>>> Xmodem sectors/kbytes sent: 545/68kRetry 0: NAK on sector
>>> Xmodem sectors/kbytes sent: 956/119kRetry 0: NAK on sector
>>> Xmodem sectors/kbytes sent: 2369/296kRetry 0: NAK on sector
>>> Xmodem sectors/kbytes sent: 2657/332kRetry 0: NAK on sector
>>> Retry 0: TIMEOUT 206
>>> Retry 0: TIMEOUT 335
>>> Retry 0: TIMEOUT 188
>>> Retry 0: TIMEOUT 655
>>> Retry 0: TIMEOUT 975
>>> Bytes received: 538368 BPS:17089
>>
>> That's scary. On the bright side, you've found an easy to replicate
>> test case that demonstrates a bug in the pty layer, I think. :((
>
> I think this might be related to this commit:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3
>
> The patch that was reverted in that commit is almost equal to the
> patch I applied!

Not really. The patch was reverted because pty_write is reportedly
called from IRQ context and the flush_to_ldisc-code reportedly
acquires 'process context' locks (which can cause the caller sleep)
which is not allowed in IRQ context. Also, this modification was done
in tty_close, to flush data upon close, while the experimental
modification I suggested was intended to cause 'flushing of data'
during write. What might also help with your problem, though, is this:

index ff47907..973be2f 100644 (file)
--- a/drivers/char/n_tty.c
+++ b/drivers/char/n_tty.c
@@ -1583,6 +1583,7 @@ static int n_tty_open(struct tty_struct *tty)

static inline int input_available_p(struct tty_struct *tty, int amt)
{
+ tty_flush_to_ldisc(tty);
if (tty->icanon) {
if (tty->canon_data)
return 1;

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/char/n_tty.c;h=973be2f441951ed0e68d658c1192c94524f33aff;hp=ff47907ff1bf9f9ae8ddc3e073c06ae4f3a615df;hb=e043e42bdb66885b3ac10d27a01ccb9972e2b0a3;hpb=7d3e91b8a1f5179d56a7412d4b499f2d5fc6b25d

This is the inverse operation, so to say: As opposed to pushing the
data on write, a reading process is trying to pull data before it
blocks in the kernel waiting for input to arrive.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Linking problem using autotool
Next: why do the Muslims bow down to ward the Ka'