4 files changed, 158 insertions, 0 deletions
diff --git a/results/classifier/108/other/1639 b/results/classifier/108/other/1639
new file mode 100644
index 000000000..e0b173017
--- /dev/null
+++ b/results/classifier/108/other/1639
@@ -0,0 +1,16 @@
+device: 0.797
+performance: 0.716
+other: 0.643
+network: 0.500
+graphic: 0.496
+semantic: 0.319
+permissions: 0.297
+debug: 0.226
+files: 0.197
+PID: 0.114
+socket: 0.090
+boot: 0.067
+vnc: 0.048
+KVM: 0.025
+
+No supported machine for loongson-3A4000 mips64el
diff --git a/results/classifier/108/other/1639322 b/results/classifier/108/other/1639322
new file mode 100644
index 000000000..98124e7e6
--- /dev/null
+++ b/results/classifier/108/other/1639322
@@ -0,0 +1,46 @@
+graphic: 0.864
+other: 0.706
+performance: 0.667
+debug: 0.610
+semantic: 0.572
+device: 0.552
+permissions: 0.515
+PID: 0.487
+network: 0.456
+files: 0.425
+vnc: 0.398
+socket: 0.369
+boot: 0.211
+KVM: 0.102
+
+pasting into ppc64 serial console kills qemu
+
+- run qemu-system-ppc64
+- when X window appears press Ctrl+Alt+3
+- paste any text longer than 16 characters
+
+
+qemu-system-ppc64: /home/abuild/rpmbuild/BUILD/qemu-2.6.1/hw/char/spapr_vty.c:40: vty_receive: Assertion `(dev->in - dev->out) < 16' failed.
+Aborted (core dumped)
+
+Broken in SUSE Leap 42.2 and git 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414
+
+What user interface are you using? VNC? SDL? GTK?
+
+This is gtk interface.
+
+However, the function on line 40 os spapr_vty.c looks really insane.
+
+It asserts that it is not given more data to input in a ring buffer than is size of the buffer and then stuffs all the data in regardless of the amount of data already present.
+
+It should probably loop or one of its callers but I did not find a decent comparable piece of code to cut and paste whatever callbacks are needed for the other side to consume the bytes.
+
+OK, seems like you need to compile QEMU with CONFIG_VTE enabled (i.e. with the vte-devel packages installed before running configure) to get copy-n-paste support in the GTK interface, that's why I was initially not able to reproduce this issue.
+Anyway, now I can trigger the assert(), too, and I've suggested a patch here:
+
+http://marc.info/?<email address hidden>
+
+FWIW, the crash should be fixed by this commit here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7bacfd7f7289192c83330
+(but we still need to fix the gtk side, too, to only send as much characters at once as the receiving side can take)
+
diff --git a/results/classifier/108/other/1639791 b/results/classifier/108/other/1639791
new file mode 100644
index 000000000..5e046e00f
--- /dev/null
+++ b/results/classifier/108/other/1639791
@@ -0,0 +1,48 @@
+device: 0.861
+KVM: 0.804
+graphic: 0.775
+vnc: 0.753
+debug: 0.747
+files: 0.739
+other: 0.687
+performance: 0.666
+semantic: 0.617
+PID: 0.592
+network: 0.586
+permissions: 0.582
+boot: 0.487
+socket: 0.398
+
+early virtio console output is lost
+
+This is broken in git and reportedly in 2.5 through 2.7.
+
+Running a Linux kernel which includes a testsuite in initrd sometimes produces no output.
+
+Reportedly the console is sometimes not open when the early userspace tries to log output resulting in either the testsuite terminating early or not writing the output.
+
+Workaround patch is here:
+
+https://git.zx2c4.com/WireGuard/commit/?id=d2de8b0862a7fbb51a7f2f958d58f0efe4648259
+
+reportedly you would get -EBADF there when no output is generated.
+
+Also this reportedly happens with virtio console only, not virtio serial port.
+
+It seems that the author of said testsuite did not report the problem so I write it down so it does not get lost.
+
+test (in bash):
+
+n=0 ; while [ $n -lt 100 ] && grep -m 1 -F "WireGuard Test Suite on Linux 4.8.6" <( /opt/qemu/bin/qemu-system-x86_64         -nodefaults         -nographic         -machine q35,accel=kvm         -cpu host         -smp 2         -m 64M         -object rng-random,id=rng0,filename=/dev/urandom         -device virtio-rng-pci,rng=rng0         -device virtio-serial,max_ports=2         -chardev stdio,id=stdio         -device virtconsole,chardev=stdio         -chardev file,id=status,path=result.txt         -device virtserialport,chardev=status         -monitor none         -kernel wireguard-testing-harness-bzImage-e87cb2a7-145c-4985-907f-17e81fae329b         -append "console=hvc0 initcall_debug=1 loglevel=7" ) ; do echo $n ; n=$(expr $n + 1) ; pkill -f wireguard ; done
+
+This typically does 10-20 iterations but sometimes tens of iterations run without issue.
+
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
+"Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1639983 b/results/classifier/108/other/1639983
new file mode 100644
index 000000000..c639de2b1
--- /dev/null
+++ b/results/classifier/108/other/1639983
@@ -0,0 +1,48 @@
+graphic: 0.911
+device: 0.878
+network: 0.866
+semantic: 0.853
+other: 0.827
+debug: 0.827
+permissions: 0.816
+vnc: 0.802
+performance: 0.799
+files: 0.776
+socket: 0.750
+PID: 0.727
+boot: 0.669
+KVM: 0.409
+
+e1000 EEPROM have bad checksum
+
+I am using qemu-system-i386 to emulate FreeDOS with e1000 nic card.
+
+I am using Intel PRODOS v.19.0 (latest version with E1000ODI.COM file).
+E1000ODI.COM v.5.07 (140116)
+
+http://pclosmag.com/html/issues/201208/page11.html
+Suggest that v.4.75 (120212) was/is working.
+Oldest PRODOS available version seems now 18.5 (June 2013) which I have not tested yet.
+
+When running it, it detect: Slot 18, IRQ 11, Port C000.
+
+But complains:
+EEPROM checksum was incorrect.
+
+Contact your services network supplier for a replacement.
+
+paul@paul89473:~$ qemu-system-i386 --version
+QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu5), Copyright (c) 2003-2008 Fabrice Bellard
+paul@paul89473:~$
+
+I'm also seeing this issue with version 2.11. Currently Intel's oldest available is 18.4 and this version reports an invalid checksum. The E1000.dos file when loaded doesn't recognize the emulated NIC. 
+
+I was able to get the e1000odi DOS driver to correctly detect the Intel e1000e once I added a PCIe bus, however the e1000 still reports a bad checksum as of this posting with the master branch.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
+"Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+