On Fri, 4 Sep 2009, Linus Torvalds wrote:
>
> And I suspect that that means that the bug is related to do_output_char()
> expanding '\n' into '\r\n'. And the different buffering (and the pty
> 'space' logic) just means that we now hit a case that we didn't use to
> hit. The relevant call chain is
>
> - n_tty handling:
> n_tty_write() ->
> process_output() ->
> do_output_char() ->
> tty_put_char(tty, '\r')
> tty_put_char(tty, '\n')
Hmm. I think I have a clue.
process_output() does
space = tty_write_room(tty);
retval = do_output_char(c, tty, space);
so 'space' can never become off-by-one, since it's always re-calculated
just before. And do_output_char() checks that there is room for two
characters, and won't do just the '\r'.
So the fact that you see the '\r' and not the '\n' means that something
dropped the second character _despite_ tty_write_room() saying there was
room for two characters.
Now, with flow control that can in theory happen in case 'tty->stopped'
gets set asynchronously in between, but that's not an issue here.
So the most likely cause is just that the pty_write_room() function is
simply buggered, or at least doesn't work together with the new world
order.
How about something like this? It's way too anal - it says that we can
only write data if there's enough space to always push it all the way to
the receive buffer (including all the data that was already buffered up,
ie the "memory_used" part). But if it finally makes the problem go away,
we have another clue.
Linus
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
