6 files changed, 270 insertions, 0 deletions
diff --git a/results/classifier/108/other/1832 b/results/classifier/108/other/1832
new file mode 100644
index 00000000..3c665df3
--- /dev/null
+++ b/results/classifier/108/other/1832
@@ -0,0 +1,16 @@
+performance: 0.650
+device: 0.531
+other: 0.430
+semantic: 0.341
+graphic: 0.265
+PID: 0.122
+vnc: 0.104
+boot: 0.104
+permissions: 0.083
+network: 0.067
+socket: 0.027
+KVM: 0.018
+debug: 0.017
+files: 0.005
+
+i386 test registers are not handled
diff --git a/results/classifier/108/other/1832250 b/results/classifier/108/other/1832250
new file mode 100644
index 00000000..9137b705
--- /dev/null
+++ b/results/classifier/108/other/1832250
@@ -0,0 +1,77 @@
+permissions: 0.883
+other: 0.877
+vnc: 0.844
+graphic: 0.828
+performance: 0.814
+semantic: 0.808
+files: 0.801
+debug: 0.797
+PID: 0.793
+socket: 0.788
+device: 0.785
+KVM: 0.760
+network: 0.737
+boot: 0.699
+
+arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-compilation
+
+FROM arm32v6/golang:1.10-alpine
+
+docker build -t openhorizon/ibm.gps_arm:2.0.7 -f ./Dockerfile.arm .
+Sending build context to Docker daemon  110.6kB
+Step 1/12 : FROM arm32v6/golang:1.10-alpine
+1.10-alpine: Pulling from arm32v6/golang
+05276f4299f2: Pull complete 
+5657e63df536: Pull complete 
+febca98d0249: Pull complete 
+5053a7aa5dea: Pull complete 
+d048463a3701: Pull complete 
+b628c679d668: Pull complete 
+Digest: sha256:94c5fd97b17d0e9fe89e011446bedda4784cb0af7a60494989e2a21c0dcba92f
+Status: Downloaded newer image for arm32v6/golang:1.10-alpine
+ ---> 3110964e8c9a
+Step 2/12 : RUN apk --no-cache update && apk add git
+ ---> Running in 14ffb11506bb
+fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz
+fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz
+v3.9.4-24-g4e2ff29bbe [http://dl-cdn.alpinelinux.org/alpine/v3.9/main]
+v3.9.4-25-g65097c9cdc [http://dl-cdn.alpinelinux.org/alpine/v3.9/community]
+OK: 9547 distinct packages available
+fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz
+fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz
+(1/7) Installing nghttp2-libs (1.35.1-r0)
+(2/7) Installing libssh2 (1.8.2-r0)
+(3/7) Installing libcurl (7.64.0-r2)
+(4/7) Installing libgcc (8.3.0-r0)
+(5/7) Installing expat (2.2.6-r0)
+(6/7) Installing pcre2 (10.32-r1)
+(7/7) Installing git (2.20.1-r0)
+Executing busybox-1.29.3-r10.trigger
+OK: 18 MiB in 22 packages
+Removing intermediate container 14ffb11506bb
+ ---> 6890ea7ed09b
+Step 3/12 : RUN mkdir -p /build/bin
+ ---> Running in 44e52d78d7b4
+Removing intermediate container 44e52d78d7b4
+ ---> 0763afda41d1
+Step 4/12 : COPY src /build/src
+ ---> 05bab9a72a34
+Step 5/12 : WORKDIR /build
+ ---> Running in 5a663caff249
+Removing intermediate container 5a663caff249
+ ---> 5a6ca53c00de
+Step 6/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go get github.com/kellydunn/golang-geo
+ ---> Running in 05b09ee0c206
+Removing intermediate container 05b09ee0c206
+ ---> e68c6e222e51
+Step 7/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go
+ ---> Running in ea6d2707e35f
+qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
+qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
+The command '/bin/sh -c env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go' returned a non-zero code: 139
+make: *** [build] Error 139
+
+Please can you try with a more recent version of QEMU? 2.8 is pretty old, and there are definitely some bugs involving Alpine Linux glibc and also go that we've fixed in later versions.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1832353 b/results/classifier/108/other/1832353
new file mode 100644
index 00000000..ed873234
--- /dev/null
+++ b/results/classifier/108/other/1832353
@@ -0,0 +1,72 @@
+device: 0.784
+files: 0.699
+permissions: 0.625
+network: 0.621
+PID: 0.618
+debug: 0.601
+other: 0.595
+graphic: 0.592
+socket: 0.586
+vnc: 0.569
+performance: 0.567
+semantic: 0.511
+boot: 0.470
+KVM: 0.245
+
+cpu_exec: Assertion !have_mmap_lock() failed
+
+Hi,
+
+I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of:
+
+qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed.
+
+including with master qemu as of today.
+
+I'm attaching a tarball containing:
+qemu-assert:
+cmd  lib  proc_ptr_51.exe
+
+qemu-assert/lib:
+ld-linux-armhf.so.3  libc.so.6  libgcc_s.so.1  libgfortran.so.5  libm.so.6
+
+where cmd is the basic command used to launch the test & reproduce the failure.
+
+Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts.
+
+
+
+What version of qemu where you running? My HEAD is failing in a different way.
+
+It's fairly recent:
+qemu-arm version 4.0.50 (v4.0.0-1215-ga578cdf-dirty)
+Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
+
+commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf
+Merge: 19735c8 43b3952
+Author: Peter Maydell <email address hidden>
+Date:   Mon Jun 10 16:09:19 2019 +0100
+
+     Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190610' into staging
+
+     Move softmmu tlb into CPUNegativeOffsetState
+
+configured with:
+--target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-debug
+
+Confirmed.  The exact failure mode depends on debugging enabled or not.
+
+The test case is "buggy" in the sense that it makes a call to a NULL
+function pointer, and the failure happens while trying to translate
+the instructions at address 0.
+
+That said, the correct behaviour for QEMU is a SIGSEGV delivered to
+the guest, not an assertion failure.
+
+The fix for this bug is now in master and will be in QEMU 4.1.
+
+
+See series: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02189.html
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=52ba13f042714c4086416
+
diff --git a/results/classifier/108/other/1832422 b/results/classifier/108/other/1832422
new file mode 100644
index 00000000..fce77f96
--- /dev/null
+++ b/results/classifier/108/other/1832422
@@ -0,0 +1,35 @@
+device: 0.667
+performance: 0.561
+network: 0.510
+socket: 0.486
+files: 0.473
+graphic: 0.457
+semantic: 0.453
+vnc: 0.413
+permissions: 0.389
+boot: 0.294
+other: 0.278
+PID: 0.268
+debug: 0.226
+KVM: 0.224
+
+SSE CMP ops with 8bit immediate throw sigill with oversized byte
+
+The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized.
+
+Test op that I found this on is here `66 0f c2 c0 d1          cmppd  xmm0,xmm0,0xd1`
+According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant)
+Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask.
+
+I have a small patch that fixes the issue for the SSE variant.
+
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/184
+
+
diff --git a/results/classifier/108/other/1832535 b/results/classifier/108/other/1832535
new file mode 100644
index 00000000..cac085da
--- /dev/null
+++ b/results/classifier/108/other/1832535
@@ -0,0 +1,40 @@
+graphic: 0.618
+device: 0.461
+semantic: 0.421
+other: 0.331
+debug: 0.320
+socket: 0.287
+network: 0.285
+performance: 0.279
+boot: 0.261
+vnc: 0.244
+PID: 0.234
+files: 0.119
+KVM: 0.105
+permissions: 0.105
+
+[riscv/regression] Missing tlb flush introduced in refactoring
+
+Hello,
+
+In qemu-system-riscv64, following a QEMU update, I get all sort of weird and not easily reproducible crashes in my risc-v guest.
+
+I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b.
+Some TLB flushes were removed in the following places:
+target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
+target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
+
+Adding TLB flushes in all 4 places fixes the issues for me.
+
+Hello,
+
+Thanks for reporting a bug.
+
+Can you please include details to reproduce the problems that you are seeing? This includes images and command line arguments.
+
+Do you also mind including the diff of what fixes the problem for you?
+
+Alistair
+
+It has been solved thanks to the mailing-list members.
+
diff --git a/results/classifier/108/other/1832914 b/results/classifier/108/other/1832914
new file mode 100644
index 00000000..5f9095a2
--- /dev/null
+++ b/results/classifier/108/other/1832914
@@ -0,0 +1,30 @@
+device: 0.874
+semantic: 0.783
+files: 0.733
+graphic: 0.731
+PID: 0.603
+network: 0.566
+performance: 0.563
+debug: 0.545
+permissions: 0.536
+boot: 0.523
+other: 0.459
+socket: 0.420
+vnc: 0.347
+KVM: 0.267
+
+Wrong error log when drive is specified qcow but qcow2 image file used.
+
+On archlinux qemu version 4.0.0 when I type:
+
+$ qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...
+
+I get this output in stderr 
+
+qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...: Unsupported qcow version 3
+
+image.qcow2 is a qcow2 image created by qemu-img. error states that problem is with lack support with qcow3 format but real problem is that foramt=qcow is wrong option.
+
+Fix has been included here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=197bfa7da7c8eeb39aa5
+