3 files changed, 199 insertions, 0 deletions
diff --git a/results/classifier/118/x86/1828 b/results/classifier/118/x86/1828
new file mode 100644
index 00000000..a22dbc82
--- /dev/null
+++ b/results/classifier/118/x86/1828
@@ -0,0 +1,51 @@
+x86: 0.922
+device: 0.840
+graphic: 0.764
+performance: 0.712
+hypervisor: 0.560
+semantic: 0.436
+kernel: 0.430
+i386: 0.409
+PID: 0.372
+risc-v: 0.342
+network: 0.329
+vnc: 0.296
+debug: 0.291
+register: 0.242
+virtual: 0.235
+socket: 0.219
+architecture: 0.217
+VMM: 0.205
+arm: 0.200
+files: 0.190
+permissions: 0.190
+user-level: 0.182
+ppc: 0.158
+KVM: 0.155
+boot: 0.154
+mistranslation: 0.152
+TCG: 0.116
+assembly: 0.104
+peripherals: 0.093
+
+[v8.0.4 regression] `qemu-system-x86_64: -accel hvf: Unknown Error`
+Description of problem:
+`-accel hvf` crashes with "Unknown Error".
+Regression in v8.0.4.
+
+The master branch doesn't seem affected.
+Steps to reproduce:
+v8.0.3:
+```console
+$ qemu-system-x86_64 -accel hvf
+(shows iPXE screen, as expected)
+```
+
+v8.0.4:
+```console
+$ qemu-system-x86_64 -accel hvf
+qemu-system-x86_64: -accel hvf: Unknown Error
+Abort trap: 6
+```
+Additional information:
+
diff --git a/results/classifier/118/x86/1828429 b/results/classifier/118/x86/1828429
new file mode 100644
index 00000000..2adfaf29
--- /dev/null
+++ b/results/classifier/118/x86/1828429
@@ -0,0 +1,53 @@
+x86: 0.829
+graphic: 0.768
+architecture: 0.714
+kernel: 0.694
+semantic: 0.659
+network: 0.571
+TCG: 0.567
+device: 0.523
+socket: 0.363
+ppc: 0.351
+user-level: 0.305
+performance: 0.296
+register: 0.295
+hypervisor: 0.240
+vnc: 0.230
+peripherals: 0.228
+PID: 0.213
+virtual: 0.202
+boot: 0.199
+files: 0.189
+mistranslation: 0.183
+permissions: 0.172
+i386: 0.162
+arm: 0.158
+debug: 0.149
+risc-v: 0.125
+VMM: 0.099
+assembly: 0.068
+KVM: 0.048
+
+qemu-system-aarch64 crashes with assertion failed while running GCC 9 test suite
+
+I am using QEMU 4.0.0 on an x86_64 Linux 4.19.0 host, the guest is an Aarch64 linux 5.0.0 system. The same issue occurred on QEMU 3.1.0.
+
+While running the GCC 9.1 test suite on the guest system, QEMU crashes with:
+
+qemu-system-aarch64: [...]/qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed.
+
+I am able to reproduce the issue reliably, which is encouraging. The full QEMU command line is:
+
+qemu-system-aarch64 -kernel kernel-5.0.0cbl1 -append "root=/dev/vda1 ro init=/sbin/init console=ttyAMA0" -name guest=cbl -drive file=cbl.qcow2,index=0,media=disk,format=qcow2 -drive file=swap.qcow2,index=1,media=disk,format=qcow2 -machine virt -cpu cortex-a57 -smp 4,sockets=1,cores=2,threads=2 -m size=8192 -netdev tap,id=network0,ifname=tapcbl2,script=no,downscript=no -device virtio-net-device,netdev=network0,mac=aa:bb:cc:dd:ee:02 -nographic
+
+The specific GCC test that causes QEMU to crash is vldX.c run from advsimd-intrinsics.exp; I can reproduce via "make check-gcc RUNTESTFLAGS=advsimd-intrinsics.exp=vldX.c"
+
+If there is anything I can do to further triage the issue, or gain more insight into what is going on, please let me know! I am eager to help however I can.
+
+Hi -- this looks rather like bug #1824853, which exists in QEMU 4.0 but which we have fixed in git. Could you try with a build of QEMU from current head-of-git to confirm that it's fixed there ?
+
+
+I'm on it. Will follow up when I have a result.
+
+Confirmed, this is a duplicate of 1824853 and is resolved in 68a7b9724fe80bedb85060bde605213ce3f9baec.
+
diff --git a/results/classifier/118/x86/1828507 b/results/classifier/118/x86/1828507
new file mode 100644
index 00000000..791fba89
--- /dev/null
+++ b/results/classifier/118/x86/1828507
@@ -0,0 +1,95 @@
+x86: 0.808
+register: 0.716
+architecture: 0.697
+ppc: 0.693
+graphic: 0.679
+device: 0.671
+network: 0.600
+boot: 0.561
+semantic: 0.550
+PID: 0.513
+socket: 0.508
+permissions: 0.499
+kernel: 0.474
+performance: 0.459
+assembly: 0.445
+debug: 0.436
+vnc: 0.435
+peripherals: 0.429
+user-level: 0.423
+mistranslation: 0.391
+hypervisor: 0.372
+files: 0.368
+risc-v: 0.343
+VMM: 0.316
+TCG: 0.306
+arm: 0.301
+i386: 0.278
+virtual: 0.238
+KVM: 0.163
+
+qemu-system-ppc64 smp crash on manual reset
+
+Host Environment:
+   x86_64 Linux v5.0.2
+   QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4)
+   SLOF:
+       Build Date = Jan 14 2019 18:00:39
+       FW Version = git-a5b428e1c1eae703
+
+Problem: Qemu crash immediately after a manual reset
+         (this is not the initial reset which launches the guest).
+
+Steps:
+
+1. Download Debian ppc64el mini.iso:
+   http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso
+2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a single CPU, I was unable
+   to reproduce the crash.
+   qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso
+3. SLOF prints the version info on the serial device, and proceeds to boot.
+4. After a few seconds, the GRUB menu appears on the VGA screen.
+5. Select one of the install options (I have tested with Default and Expert), and wait
+   for the Debian's text-mode installer (blue-gray-red) screen to appear.
+6. Click Machine->Reset (or enter system_reset on the qemu monitor).
+7. Notice that, on the serial device, SLOF has printed the version info. That is, the system
+   has reset and is attempting to boot again.
+8. On the host cmd prompt, qemu dies after printing this fatal error and spewing the
+   contents of the CPU registers:
+
+   qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support
+   <CPU contents> (See attached out.txt for details)
+   Aborted (core dumped)
+
+
+The HV exception is either
+   (a) 70 = HISI, which occurs when NIP contains an outright bogus or inaccessible value, or
+   (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner value, and
+       the cpu attempts to run the instruction at that address.
+
+The exception can occur on either of the CPUs. It occurs when qemu is running the SLOF
+code.
+
+
+
+If one continues with the iso, and installs the OS in the
+guest, the rebooting of the guest from within the guest
+OS too causes qemu to exit fatally. So, one can run
+'systemctl reboot' or 'reboot' within the guest OS and
+see qemu crash (immediately after SLOF prints version,
+etc. as part of the reboot sequence, as described before).
+
+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 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". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+