1 files changed, 109 insertions, 0 deletions
diff --git a/results/classifier/118/none/1399943 b/results/classifier/118/none/1399943
new file mode 100644
index 000000000..7693322ae
--- /dev/null
+++ b/results/classifier/118/none/1399943
@@ -0,0 +1,109 @@
+graphic: 0.644
+permissions: 0.554
+network: 0.541
+device: 0.510
+register: 0.510
+debug: 0.488
+semantic: 0.470
+peripherals: 0.464
+files: 0.460
+architecture: 0.459
+socket: 0.457
+PID: 0.455
+virtual: 0.452
+ppc: 0.450
+assembly: 0.448
+performance: 0.437
+arm: 0.436
+hypervisor: 0.414
+vnc: 0.389
+risc-v: 0.382
+i386: 0.358
+user-level: 0.358
+x86: 0.347
+KVM: 0.347
+boot: 0.345
+VMM: 0.328
+mistranslation: 0.309
+TCG: 0.308
+kernel: 0.252
+
+qemu-system-sparc loses serial console data on EAGAIN
+
+When running a guest OS with a serial console under 
+"qemu-system-sparc -nographic", parts of the serial console output
+are sometimes lost.
+
+This happens when a write() to standard output by qemu returns EAGAIN,
+as may be the case when the guest is generating console output faster
+than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
+output accepts it. The bug affects all releases of qemu since 1.5,
+which was the first version to set stdout to O_NONBLOCK mode. Version
+1.4.2 and earlier work correctly.
+
+To reproduce the bug, you will need a guest OS configured with a
+serial console, and a host with a slow tty.  The attached shell script
+"sparc-test.sh" does this by using Aboriginal Linux as the serial
+console guest, and a pty controlled by a Python script and the
+"pexpect" Python module as the slow tty. A "seq" command is sent
+to the guest to generate 100,000 lines of output containing sequential
+integers, and the output is checked for gaps. The script limits the
+tty output rate by occasionally sleeping for 1/10 of a second.
+
+This bug was originally reported against qemu-system-i386 as 
+bug #1335444, and has since been fixed in qemu-system-i386,
+but remains in qemu-system-sparc as of today's git sources 
+(d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
+this separate bug for the sparc case because I was asked
+to do so by Paolo Bonzini in #1335444.
+
+
+
+The automated test infrastructure of the NetBSD project is based on
+qemu, and runs some 100 CPU-hours per day of full system tests of
+NetBSD-current on emulated i386, amd64, and sparc systems.
+
+This is all still running on qemu 0.15 (!).  The main obstacle to
+upgrading to a current version of qemu is this three-year-old regression
+which breaks the sparc tests by losing some of the serial console output.
+
+It would be really nice if this could be fixed.
+
+
+Hi Andreas,
+
+I've just done a local test using git master qemu-system-sparc here and your test script passes (i.e. reaches 100000 iterations) without any failures locally. I know that Daniel has done a lot of work in this area in the past 2 releases so perhaps this has fixed the issue. Please can you test locally with git master and report back?
+
+
+Many thanks,
+
+Mark.
+
+
+Hi Mark,
+
+I tested the git master and the 2.7.0 release, and both successfully executed the scripted NetBSD/sparc install that had been failing since 1.5.
+
+So it does indeed look like the bug has been fixed.  I will still run a few more tests to be sure, and if those also pass, this bug report can be closed.  Thank you.
+
+
+I have now run some more tests, and I'm still seeing occasional failures in the scripted NetBSD installs that look like console data loss when using qemu 2.7.0, with maybe one in ten installs failing.  I have seen no failures so far using the git master.  So it looks like the bug is fixed in git, but not yet in 2.7.0.
+
+
+Hi Andreas,
+
+Does the new 2.8 release pass your tests? If so, I will close this bug report.
+
+
+ATB,
+
+Mark.
+
+
+Hi Mark,
+
+I have now upgraded to qemu 2.8 and successfully run more than 20 scripted installs of NetBSD/sparc over a serial console without failures, so it does indeed look like the bug is now fixed, and the bug report can be closed.
+
+
+Fix confirmed in QEMU 2.8 release.
+