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.
pgpFTJQt2jdWs.pgp
Description: PGP signature
