On Thu, Feb 17, 2005 at 07:45:56AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 16 Feb 2005, Theodore Ts'o wrote:
> >
> > Yes, but then when the buffer is full, and we return the "we'll take
> > anything" return value, the code that was getting confused with the
> > "incorrect" receive_room value
On Wed, 16 Feb 2005, Theodore Ts'o wrote:
>
> Yes, but then when the buffer is full, and we return the "we'll take
> anything" return value, the code that was getting confused with the
> "incorrect" receive_room value will still be getting confused
But that's fine - at that point we're lite
On Wed, Feb 16, 2005 at 08:06:00AM -0800, Linus Torvalds wrote:
> Yes, yes, but did you see my suggested version that I had just below that
> explained what I thought the real fix was?
>
> Th eproblem with checking for the "canon but no canon data" is that it's a
> special case that IS ONLY VALID
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
>
> On Wed, 16 Feb 2005, Roman Zippel wrote:
> >
> > Below is a new patch, which also fixes problems with very long lines.
>
> Ok, I agree with this one, but won't dare to apply it right now. Remind me
> post-2.6.11, or - even better - see if one o
On Wed, 16 Feb 2005, Roman Zippel wrote:
>
> Below is a new patch, which also fixes problems with very long lines.
Ok, I agree with this one, but won't dare to apply it right now. Remind me
post-2.6.11, or - even better - see if one of the alternate trees wants to
fix and test this (-mm, -ac,
Hi,
On Tue, 15 Feb 2005, Linus Torvalds wrote:
> So I'd still worry whether that added -1 actually fixes the bug, or just
> means that a off-by-one has to now be off-by-two to be noticeable..
You're right, even if one just writes 4095 bytes, it will also drop
tty->read_cnt characters later.
>
On Wed, 16 Feb 2005, Theodore Ts'o wrote:
>
> The comment above the test explains why that test is there in
> n_tty_receive_room. If that test isn't there, and we are doing input
> canonicalization, when the buffer gets full
Yes, yes, but did you see my suggested version that I had just below
On Tue, Feb 15, 2005 at 08:05:05PM -0800, Linus Torvalds wrote:
> Why have that "tty->icanon && !tty->canon_data" test in the first place, I
> wonder? Isn't the "left" calculation always correct? That's really how
> many bytes free we have in the tty, that "canon_data" thing is just about
> how
On Wed, 16 Feb 2005, Roman Zippel wrote:
>
> The patch below seems to do the trick too.
> It seems the initial receive_room() call in pty_write() returns
> N_TTY_BUF_SIZE and receive_buf() will happily drop the last byte.
Why have that "tty->icanon && !tty->canon_data" test in the first place,
Hi,
On Tue, 15 Feb 2005, Linus Torvalds wrote:
> > I've also seen more than one byte missing. For example when sending a big
> > chunk of bytes down the pty via an Emacs *shell* buffer up to 16 bytes are
> > missing somewhere in the middle.
>
> If it's NTTY (and I'm pretty certain it is - the g
On Maw, 2005-02-15 at 19:44, Linus Torvalds wrote:
> However, then when I start looking at n_tty_receive_room() and
> n_tty_receive_buf(), my stomach gets a bit queasy. I have this horrid
> feeling that I had something to do with the mess, but I'm going to lash
You did.
Then Ted tided it up
The
Linus Torvalds <[EMAIL PROTECTED]> writes:
> That's clearly not the case, and I haven't looked into exactly what
> termios settings "forkpty()" uses
If no termios is passed then the defaults are unchanged.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfe
On Tue, 15 Feb 2005, Andreas Schwab wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > 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,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> 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.
I've also seen more than one
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 disci
Linus Torvalds writes the following:
>
>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 t
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
On Tue, 15 Feb 2005, 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 als
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,
On Tuesday 15 February 2005 11:48, Andreas Schwab wrote:
> Alex Davis <[EMAIL PROTECTED]> writes:
> > Problem does not exist on 2.6.8.1.
>
> Yes, it is a pretty recent regression, reproducable since 2.6.10.
Confirmed against 2.6.11-rc4
[EMAIL PROTECTED]:/tmp$ ./a.out < laptop-mode.txt | diff lapt
Alex Davis <[EMAIL PROTECTED]> writes:
> Problem does not exist on 2.6.8.1.
Yes, it is a pretty recent regression, reproducable since 2.6.10.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7
Problem does not exist on 2.6.8.1. Compiling your program and running
./a.out < README | diff README -
produces no output.
I tested various files ranging in size from 10 to 60k.
-Alex
=
I code, therefore I am
__
Do you Yahoo!?
Yahoo! Ma
Recent kernel are losing bytes on a pty. Try running this program (needs
to be linked against -lutil) with a moderately large input (10K - 20K).
The output should match its input, but instead there is always one byte
missing at the end of the first 4K chunk read by the child.
#include
#include
23 matches
Mail list logo
