On Fri, 4 Sep 2009, Mikael Pettersson wrote: > > Comparing the gcc outputs for this test case from runs with 2.6.30 and > 2.6.31-rc8 shows that 2.6.31-rc8 lost a single newline (\n) byte at byte > offset 131660. So two lines of diagnostics were fused together and the > testsuite framework failed to match the second of those lines. Goodie. That was the kind of hint I was looking for. 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') I'll see what I can find. But your "loses \n character" does mean that the 'lost bytes at the end when the other end closed it' is probably not the issue, and we're talking about a different kind of bug entirely. 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
