8 files changed, 429 insertions, 0 deletions
diff --git a/results/classifier/118/none/155 b/results/classifier/118/none/155
new file mode 100644
index 00000000..0737349b
--- /dev/null
+++ b/results/classifier/118/none/155
@@ -0,0 +1,31 @@
+architecture: 0.784
+device: 0.756
+performance: 0.626
+mistranslation: 0.496
+hypervisor: 0.446
+graphic: 0.399
+semantic: 0.339
+debug: 0.212
+virtual: 0.204
+user-level: 0.202
+network: 0.162
+arm: 0.142
+i386: 0.131
+x86: 0.118
+peripherals: 0.106
+boot: 0.064
+risc-v: 0.061
+ppc: 0.059
+assembly: 0.056
+files: 0.052
+permissions: 0.050
+register: 0.039
+socket: 0.031
+TCG: 0.025
+vnc: 0.022
+kernel: 0.020
+PID: 0.017
+KVM: 0.014
+VMM: 0.010
+
+MMX emulation is missing on HVF Acceleration
diff --git a/results/classifier/118/none/1550743 b/results/classifier/118/none/1550743
new file mode 100644
index 00000000..3f19cdf4
--- /dev/null
+++ b/results/classifier/118/none/1550743
@@ -0,0 +1,60 @@
+graphic: 0.557
+mistranslation: 0.516
+i386: 0.422
+semantic: 0.402
+device: 0.369
+performance: 0.362
+x86: 0.342
+architecture: 0.316
+permissions: 0.289
+PID: 0.275
+network: 0.271
+peripherals: 0.256
+user-level: 0.237
+register: 0.217
+socket: 0.176
+files: 0.171
+debug: 0.155
+kernel: 0.136
+ppc: 0.134
+hypervisor: 0.126
+assembly: 0.122
+boot: 0.113
+vnc: 0.108
+arm: 0.097
+virtual: 0.081
+risc-v: 0.075
+TCG: 0.043
+VMM: 0.037
+KVM: 0.037
+
+connect low speed host devices to qemu ehci does not work
+
+$ qemu-system-i386 -hda my_x86.img -device ich9-usb-ehci1,id=ehci -device usb-host,vendorid=0x045e,productid=0x071d -serial stdio
+qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed)
+qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed)
+qemu-system-i386: Warning: speed mismatch trying to attach usb device "Microsoft? 2.4GHz Transceiver V" ( speed) to bus "ehci.0", port "1" (high speed)
+
+Which is obviously wrong. The ehci specification states:
+
+Low-speed device, release ownership of port <= Table 2-16.
+
+Table 2-6:
+
+Number of Companion Controller (N_CC). This field indicates the number of
+companion controllers associated with this USB 2.0 host controller.
+A zero in this field indicates there are no companion host controllers. Port-ownership
+hand-off is not supported. Only high-speed devices are supported on the host controller
+root ports.
+A value larger than zero in this field indicates there are companion USB 1.1 host
+controller(s). Port-ownership hand-offs are supported. High, Full- and Low-speed
+devices are supported on the host controller root ports.
+
+Which is not longer true, as for example skylake and baytrail offers a dual usb stack of ehci and xhci. In that case, EHCI handles the low speed device as well.
+
+brgds,
+Bert
+
+Are you sure that EHCI handles low-speed devices in that case? I thought that XHCI is capable of handling low-speed devices instead...
+Anyway, QEMU certainly only emulates the EHCI in a traditional way, so if you want to use low-speed devices here, you also have to specify an UHCI controller for them. I.e. as far as I can see, this is not a bug in QEMU, but just a configuration issue.
+
diff --git a/results/classifier/118/none/1551 b/results/classifier/118/none/1551
new file mode 100644
index 00000000..f0817e1b
--- /dev/null
+++ b/results/classifier/118/none/1551
@@ -0,0 +1,70 @@
+boot: 0.753
+graphic: 0.731
+hypervisor: 0.658
+peripherals: 0.657
+performance: 0.649
+files: 0.615
+device: 0.614
+semantic: 0.611
+ppc: 0.590
+arm: 0.555
+PID: 0.553
+architecture: 0.538
+permissions: 0.513
+vnc: 0.498
+kernel: 0.489
+i386: 0.459
+x86: 0.457
+register: 0.454
+assembly: 0.451
+socket: 0.449
+user-level: 0.446
+VMM: 0.444
+risc-v: 0.411
+KVM: 0.379
+virtual: 0.373
+network: 0.372
+TCG: 0.356
+debug: 0.317
+mistranslation: 0.238
+
+qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed.
+Description of problem:
+When starting the guest, the mentioned assertion is triggered very soon:
+```
+qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed.
+```
+I'm able to successfully boot the same image with QEMU 7.2.0.
+
+The last output from the qemu logging with `-d guest_errors,in_asm,int,pcall,cpu` is
+```
+----------------
+IN:
+0x40209100:  e92d4ff0  push     {r4, r5, r6, r7, r8, sb, sl, fp, lr}
+0x40209104:  e28db020  add      fp, sp, #0x20
+0x40209108:  e24b3f49  sub      r3, fp, #0x124
+0x4020910c:  e24ddf43  sub      sp, sp, #0x10c
+0x40209110:  e1a0e00f  mov      lr, pc
+0x40209114:  e3e0f0ff  mvn      pc, #0xff
+
+R00=4021000c R01=4020a5f8 R02=0000000f R03=40209100
+R04=40210018 R05=40210018 R06=4020c000 R07=40002000
+R08=00000000 R09=00000000 R10=00000000 R11=4020d7fc
+R12=00000000 R13=4020d7f0 R14=4020074c R15=40209100
+PSR=2000011f --C- A sys32
+----------------
+IN:
+0xffffff00:  ee1d0f50  mrc      p15, #0, r0, c13, c0, #2
+
+R00=4021000c R01=4020a5f8 R02=0000000f R03=4020d6c8
+R04=40210018 R05=40210018 R06=4020c000 R07=40002000
+R08=00000000 R09=00000000 R10=00000000 R11=4020d7ec
+R12=00000000 R13=4020d6c0 R14=40209118 R15=ffffff00
+PSR=2000011f --C- A sys32
+```
+
+Please note that the L4Re OS uses `mvn pc, #0xff` to switch from EL1 to EL2 (system call).
+Steps to reproduce:
+1. Boot the attached image with the provided command line to trigger the assertion
+Additional information:
+I will attach the bootstrap image to this ticket.
diff --git a/results/classifier/118/none/1552549 b/results/classifier/118/none/1552549
new file mode 100644
index 00000000..170d8a95
--- /dev/null
+++ b/results/classifier/118/none/1552549
@@ -0,0 +1,41 @@
+device: 0.486
+debug: 0.400
+graphic: 0.358
+network: 0.333
+architecture: 0.314
+boot: 0.313
+i386: 0.312
+performance: 0.309
+virtual: 0.269
+kernel: 0.235
+semantic: 0.229
+socket: 0.217
+VMM: 0.209
+files: 0.208
+vnc: 0.184
+user-level: 0.178
+x86: 0.174
+hypervisor: 0.174
+register: 0.166
+permissions: 0.144
+arm: 0.137
+peripherals: 0.117
+risc-v: 0.107
+mistranslation: 0.097
+assembly: 0.087
+ppc: 0.085
+PID: 0.071
+KVM: 0.060
+TCG: 0.060
+
+qemu-system-i386 verison 2.5.50 fails at lmsw instruction
+
+I cloned qemu source code from github.com, and compiled it on my Kubuntu 15.10 laptop to run my little OS. When booting my little OS, the virtual machine's screen keep blinking, I guess it's the virtual machine rebooting on and on automatically for some unknown reason, but there is no further information shown on Kubuntu's terminal. I'm pretty sure this problem is not caused by my little OS, because it works just fine in qemu-system-i386 version 2.5.0.
+
+I debugged my OS and find this problem happens when executing instruction "lmsw ax". Is this a bug, can anyone help me out?
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? If not, can you provide an example for testing?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1555076 b/results/classifier/118/none/1555076
new file mode 100644
index 00000000..656f030b
--- /dev/null
+++ b/results/classifier/118/none/1555076
@@ -0,0 +1,79 @@
+semantic: 0.719
+graphic: 0.700
+performance: 0.699
+hypervisor: 0.697
+i386: 0.694
+device: 0.692
+architecture: 0.690
+mistranslation: 0.686
+user-level: 0.672
+permissions: 0.665
+ppc: 0.654
+files: 0.641
+virtual: 0.623
+PID: 0.613
+vnc: 0.564
+risc-v: 0.553
+x86: 0.549
+network: 0.528
+socket: 0.525
+debug: 0.511
+peripherals: 0.484
+TCG: 0.474
+VMM: 0.431
+arm: 0.428
+register: 0.421
+kernel: 0.369
+assembly: 0.322
+boot: 0.316
+KVM: 0.305
+
+Qemu 2.5 dont start with sdl,gl=on or gtk,gl=on
+
+with this config line 
+ qemu-system-i386 -m 2047 -hda /dev/sda3 -display sdl,gl=on -sdl -vga virtio -cdrom xenial-desktop-i386.iso 
+
+
+i have this exit
+
+ERROR:ui/console-gl.c:95:surface_gl_create_texture: code should not be reached
+
+same is i use this:
+
+qemu-system-i386 -m 2047 -hda /dev/sda3 -display gtk,gl=on -sdl -vga virtio -cdrom xenial-desktop-i386.iso 
+ERROR:ui/console-gl.c:95:surface_gl_create_texture: code should not be reached
+
+
+My Os i Debian Jessie  on P5020 PPC64 4GB ram GPU RadeonHD .
+Configure gave me gl ok, sdl ok , Virtio and Virgl OK .
+
+My Mesa are the 11.3 dev ... the same issue was found on oldest and stable release of mesa .
+
+OpenGL vendor string: X.Org
+OpenGL renderer string: Gallium 0.4 on AMD TURKS (DRM 2.43.0)
+OpenGL version string: 2.1 Mesa 11.3.0-devel (git-3146014)
+OpenGL shading language version string: 1.30
+
+
+OpenGL ES profile version string: OpenGL ES 2.0 Mesa 11.3.0-devel (git-3146014)
+OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
+
+
+Thanks 
+Luigi
+
+Is this the same issue as the bug reported here:
+https://bugs.launchpad.net/qemu/+bug/1581796
+?
+
+Sorry T, 
+i forget had been reported and duplicate the bug report.
+can merge or close this one.
+
+i will check with your suggestion and report.
+
+Fix has been pulled into the QEMU git repository:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c2311c5451f4555e850772
+
+Released with version 2.7
+
diff --git a/results/classifier/118/none/1556372 b/results/classifier/118/none/1556372
new file mode 100644
index 00000000..cdaad8ae
--- /dev/null
+++ b/results/classifier/118/none/1556372
@@ -0,0 +1,56 @@
+graphic: 0.796
+device: 0.638
+semantic: 0.489
+user-level: 0.437
+ppc: 0.422
+PID: 0.380
+performance: 0.365
+permissions: 0.351
+architecture: 0.351
+socket: 0.346
+files: 0.341
+vnc: 0.336
+mistranslation: 0.334
+network: 0.328
+register: 0.322
+i386: 0.314
+risc-v: 0.287
+debug: 0.272
+hypervisor: 0.239
+arm: 0.226
+x86: 0.220
+kernel: 0.207
+boot: 0.205
+peripherals: 0.203
+TCG: 0.169
+assembly: 0.168
+VMM: 0.167
+KVM: 0.167
+virtual: 0.119
+
+Superfluous popup on Cocoa to verify quit, cannot be disabled.
+
+This patch severely reduces the quality of life for developers using QEMU in a rapid Edit-Compile-Test cycle.
+Any method of quitting QEMU via the UI triggers this dialogue, whose default option is "cancel" -- necessitating the use of the mouse to click "Confirm".
+
+This dialogue cannot be disabled by any flag, and is highly annoying. Recommend a flag to disable this confirmation, or in fact disable it by default and enable it with a flag.
+
+Patch in question:
+
+https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html
+
+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.]
+
diff --git a/results/classifier/118/none/1557 b/results/classifier/118/none/1557
new file mode 100644
index 00000000..6eab99bb
--- /dev/null
+++ b/results/classifier/118/none/1557
@@ -0,0 +1,41 @@
+graphic: 0.759
+device: 0.747
+performance: 0.531
+architecture: 0.489
+register: 0.460
+semantic: 0.447
+debug: 0.396
+network: 0.372
+user-level: 0.274
+vnc: 0.256
+PID: 0.225
+socket: 0.213
+files: 0.205
+arm: 0.188
+permissions: 0.163
+mistranslation: 0.139
+VMM: 0.137
+boot: 0.132
+risc-v: 0.115
+ppc: 0.111
+virtual: 0.105
+TCG: 0.104
+peripherals: 0.094
+kernel: 0.089
+hypervisor: 0.073
+i386: 0.072
+x86: 0.060
+KVM: 0.037
+assembly: 0.029
+
+qemu-binfmt-conf.sh handles errors inconsistently
+Description of problem:
+We are installing qemu via multiarch/qemu-user-static docker image. https://github.com/multiarch/qemu-user-static
+
+What we have noticed is that because qemu-binfmt-conf.sh does not use `set -e`, its behavior with regards to failures is inconsistent. In short, registering the same thing into binfmt twice is an error (you get EEXIST). However, the exit code of qemu-binfmt-conf.sh itself seems to depend only on whether the last interpreter succeeded, leading to confusing and inconsistent results.
+Steps to reproduce:
+1. Register only qemu-arm-static interpreter with binfmt.
+2. Run qemu-binfmt-conf.sh. Observe that the exit code is zero, and logs show the duplicate interpreter was rejected.
+3. Remove all qemu interpreters.
+3. Register only qemu-loongarch64-static interpreter (currently last in qemu_target_list) with binfmt.
+3. Run qemu-binfmt-conf.sh. Observe that the exit code is non-zero, and logs show the duplicate interpreter was rejected.
diff --git a/results/classifier/118/none/1557033 b/results/classifier/118/none/1557033
new file mode 100644
index 00000000..fb90a372
--- /dev/null
+++ b/results/classifier/118/none/1557033
@@ -0,0 +1,51 @@
+peripherals: 0.781
+device: 0.773
+architecture: 0.760
+virtual: 0.759
+kernel: 0.704
+performance: 0.668
+boot: 0.663
+hypervisor: 0.610
+permissions: 0.565
+graphic: 0.548
+ppc: 0.536
+register: 0.533
+semantic: 0.523
+assembly: 0.508
+mistranslation: 0.501
+files: 0.445
+PID: 0.417
+user-level: 0.417
+arm: 0.405
+socket: 0.394
+vnc: 0.369
+network: 0.314
+KVM: 0.310
+debug: 0.308
+VMM: 0.303
+risc-v: 0.302
+x86: 0.269
+TCG: 0.252
+i386: 0.205
+
+Persistent malfunction after guest shutdown/reboot
+
+Running the VM the first time after the host has booted up is completely fine, no issues at all. However, after shutting down or restarting the VM, certain problems occur. In the Windows 10 VM, it may throw a SYSTEM_THREAD_EXCEPTION error on bootup, and other times it simply won't use the VirtIO drive. Before the latest update of QEMU 2.5.0, I have had no problems.
+
+Recently, I've also downgraded my kernel in order to solve some problems related to Haswell. This is probably the same time I've got the 2.5.0 update. When I did this, I could no longer boot into my main image due to similar problems. I've had to also update the VirtIO storage driver with a new image installation. Before I figured that everything worked fine on a host reboot, the installer would spit out an error that it could not modify the partitions of the drive. Everything else worked fine with SATA or IDE configuration, but not VirtIO. I shouldn't need to restart my computer after shutting down the computer.
+
+I've tried using QEMU with the latest Linux kernel (4.4.x) with the exact same result.
+
+Here is what I have configured:
+- Arch Linux with linux-lts (4.1.19-1-lts)
+- QEMU 2.5.0
+- VirtIO drivers v 0.1.113
+- Windows 10 from MSDN
+- vfio PCI Passthrough of NVIDIA 970
+
+I'm not sure how to get any more logs so if you need more info I'll be glad to provide it
+
+
+
+I've just recently experienced drive corruption and BIOS issues. After a reformat (to ext4 from f2fs), a BIOS re-flash and reinstall with linux-lts, this issue isn't appearing anymore so it was an issue specific to me.
+