Re: Pty is losing bytes

[Sergey Vlasov]

On Tue, Feb 15, 2005 at 10:58:02PM +0300, Sergey Vlasov wrote:
> On Tue, 15 Feb 2005 11:08:07 -0800 (PST) Linus Torvalds wrote:
> 
> > On Tue, 15 Feb 2005, Andreas Schwab wrote:
> > >
> > > Recent kernel are losing bytes on a pty. 
> > 
> > Great catch.
> > 
> > I think it may be a n_tty line discipline bug, brought on by the fact that
> > the PTY buffering is now 4kB rather than 2kB. 4kB is also the
> > N_TTY_BUF_SIZE, and if n_tty has some off-by-one error, that would explain 
> > it.
> > 
> > Does the problem go away if you change the default value of "chunk" (in 
> > drivers/char/tty_io.c:do_tty_write) from 4096 to 2048? If so, that means 
> > that the pty code has _claimed_ to have written 4kB, and only ever wrote 
> > 4kB-1 bytes. That in turn implies that "ldisc.receive_room()" disagrees 
> > with "ldisc.receive_buf()".
> 
> The problem also goes away after unsetting ECHO on the slave terminal.
> This seems to point to this code in n_tty_receive_char():
> 
> 	if (L_ECHO(tty)) {
> 		if (tty->read_cnt >= N_TTY_BUF_SIZE-1) {
> 			put_char('\a', tty); /* beep if no space */
> 			return;
> 		}
> 	.......
> 	}
> 
> This code sets the maximum number of buffered characters to
> N_TTY_BUF_SIZE-1, however, put_tty_queue() considers the maximum to be
> N_TTY_BUF_SIZE, and n_tty_receive_room() also returns N_TTY_BUF_SIZE for
> canonical mode if the canon_data buffer is empty - therefore after
> unsetting ECHO bytes are no longer lost.

But all this really is not important, because n_tty_receive_char() can
put more than one char into buffer for a single input char in lots of
cases.  Therefore n_tty_receive_room() can overestimate the available
space at least by 2 times.

Attachment: pgp00000.pgp
Description: PGP signature