Hi Peter, I updated the Bugzilla with additional information, including a strace log of both bash and sshd while reproducing the problem. strace of bash is here: https://bugzilla.kernel.org/attachment.cgi?id=178851 strace of sshd is here: https://bugzilla.kernel.org/attachment.cgi?id=178861 Looks to me like "echo" is enabled when the newline and prompt are printed, but I might have glanced something and it might not be... Please take a look. Let me know if you'd like me to instrument the kernel to gather more information about this issue. Cheers, Filipe On Wed, Jun 3, 2015 at 5:02 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > Hi Filipe, > > On 06/03/2015 01:03 AM, Filipe Brandenburger wrote: >> Hi, >> >> This seems to be a regression introduced in this commit: >> d2b6f44779d3 ("n_tty: Fix signal handling flushes") >> >> The problem is that pressing Ctrl+C on a shell through SSH is "eating" >> the output, which is usually a literal "^C", a newline and the $PS1 >> prompt. > > Thanks for the report. > > But I'm having trouble reproducing what you observe using either > native localhost or 2 machines, so this may be specific to qemu. > I assume you're shelling onto the vm? Is this an x86 vm? > >> I straced both bash and the sshd for that connection and caught it on >> a time while the problem happened. It turns out bash was indeed >> printing the "^C", newline and $PS1 but the sshd process was never >> receiving it, so it was being lost somewhere in the pty code... >> >> I tried bisecting it but it was hard since the problem wouldn't always >> reproduce... > > Could echo be off at the moment the signal char is processed? > IOW, what are you interrupting? > >> But I booted with 3.9.8 and used the vm for many hours, >> didn't notice it once, booted on 4.1-rc6 again, used it for a while >> and noticed the problem was there, > > I could see how a pty closing bug might cause this but that was fixed > for 4.1-rc3 (and was only just added to the 4.0-stable tree), so > doesn't explain observing this on 4.1-rc6. > > Regards, > Peter Hurley > >> then reverted commit d2b6f44779d3, >> rebuilt, boot it, used it for a few hours and (so far) haven't noticed >> the problem back. >> >> I'm using Arch Linux on a qemu/kvm. I noticed this problem first with >> kernel 4.0.4 from Arch, but then I tried upstream kernels and I >> noticed the same on 4.0, 4.0.4-upstream, 4.1-rc5 and 4.1-rc6. >> >> If I have some time, I'll start digging into it to figure out if I can >> trace some kernel structures when I manage to reproduce the problem. >> If you'd like me to add a kernel patch and possibly execute some >> commands for tracing while I try to reproduce the problem (to confirm >> a hypothesis you may have?) let me know, I'd be happy to help in >> trying to figure this one out. >> >> Kernel bugzilla is here: >> https://bugzilla.kernel.org/show_bug.cgi?id=99351 >> >> Cheers! >> Filipe >> > -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
