7 files changed, 546 insertions, 0 deletions
diff --git a/results/classifier/118/mistranslation-i386/1089005 b/results/classifier/118/mistranslation-i386/1089005
new file mode 100644
index 00000000..a543869c
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/1089005
@@ -0,0 +1,103 @@
+i386: 0.935
+mistranslation: 0.910
+debug: 0.895
+graphic: 0.888
+vnc: 0.882
+performance: 0.870
+semantic: 0.834
+ppc: 0.823
+user-level: 0.802
+architecture: 0.729
+device: 0.723
+hypervisor: 0.703
+register: 0.628
+network: 0.626
+virtual: 0.610
+x86: 0.602
+risc-v: 0.601
+permissions: 0.599
+kernel: 0.553
+boot: 0.540
+socket: 0.526
+arm: 0.497
+peripherals: 0.474
+TCG: 0.472
+PID: 0.454
+files: 0.445
+KVM: 0.432
+VMM: 0.418
+assembly: 0.143
+--------------------
+user-level: 0.860
+i386: 0.759
+x86: 0.568
+virtual: 0.215
+vnc: 0.115
+debug: 0.111
+hypervisor: 0.048
+PID: 0.034
+TCG: 0.028
+semantic: 0.028
+files: 0.020
+kernel: 0.017
+socket: 0.014
+performance: 0.012
+network: 0.011
+register: 0.010
+VMM: 0.005
+device: 0.005
+boot: 0.003
+architecture: 0.003
+risc-v: 0.003
+permissions: 0.002
+assembly: 0.002
+arm: 0.001
+peripherals: 0.001
+graphic: 0.001
+ppc: 0.001
+mistranslation: 0.001
+KVM: 0.000
+
+Qemu does not shutdown with vnc enabled on OS X
+
+I am running OS X 10.8.2 and Qemu 1.3.50 from your git repository.
+
+Running
+
+    qemu-system-i386 <image>
+
+works fine. I can quit the process using ctrl-c.
+
+When I try to use
+
+     qemu-system-i386 -vnc :<port> <image>
+
+ctrl-c does nothing and I have to kill the process trough the activity monitor.
+Furthermore terminating the process from my java program does not work either. 
+I have also posted a question on Stackoverflow: http://stackoverflow.com/questions/13798367/qemu-does-not-shutdown-with-vnc-enabled-on-os-x
+
+Thanks
+Leander
+
+Interesting -- my experience is that control-C doesn't work at all, even if using the cocoa UI frontend. It's a bug of some kind related to signal handling but I haven't been able to track it down. As far as I could tell with a debugger QEMU never received the SIGTERM at all, which makes no sense to me.
+
+As a workaround you can send QEMU a SIGKILL, which will abruptly terminate QEMU (NB that if you have a writable disk image you may find it is corrupt since this is a long way from a clean shutdown). The best approach would be to make the guest cleanly power down the VM, which should cause QEMU to exit automatically.
+
+
+Triaging old bug tickets ... can you still reproduce this issue with the
+latest version of QEMU (version 2.9)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+the issue is still there
+i am using 2.9.50
+i want to stop a running process when i press ctrl-c and not stop the whole qemu
+
+Rida, this bug was about stopping QEMU with CTRL-c, so I guess you tried to do something else here? What do you mean by "running process"? The emulated process that is running with QEMU?
+
+I just got the newest version of QEMU available via Homebrew (2.9.0) and was able to successfully terminate the QEMU process with ctrl-c. 
+
+@Rida: To clarify: I did want to stop the whole QEMU and that did not work at the time. I had to kill the process through the activity monitor. 
+
+Thanks for checking the latest version, Leander - I changed the status accordingly.
+
diff --git a/results/classifier/118/mistranslation-i386/1300863 b/results/classifier/118/mistranslation-i386/1300863
new file mode 100644
index 00000000..27605de6
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/1300863
@@ -0,0 +1,70 @@
+i386: 0.991
+mistranslation: 0.948
+x86: 0.934
+files: 0.918
+device: 0.895
+boot: 0.877
+graphic: 0.782
+architecture: 0.747
+semantic: 0.724
+network: 0.672
+permissions: 0.666
+performance: 0.664
+user-level: 0.630
+risc-v: 0.601
+vnc: 0.563
+socket: 0.538
+ppc: 0.532
+arm: 0.508
+PID: 0.476
+VMM: 0.464
+debug: 0.441
+register: 0.440
+peripherals: 0.429
+TCG: 0.402
+kernel: 0.356
+virtual: 0.315
+hypervisor: 0.166
+assembly: 0.136
+KVM: 0.028
+--------------------
+i386: 0.997
+virtual: 0.959
+user-level: 0.939
+x86: 0.912
+hypervisor: 0.746
+TCG: 0.125
+debug: 0.102
+boot: 0.042
+files: 0.036
+network: 0.012
+PID: 0.012
+device: 0.010
+register: 0.006
+semantic: 0.006
+socket: 0.005
+kernel: 0.004
+arm: 0.003
+peripherals: 0.003
+performance: 0.003
+vnc: 0.002
+VMM: 0.002
+assembly: 0.002
+risc-v: 0.002
+graphic: 0.001
+ppc: 0.001
+architecture: 0.001
+permissions: 0.001
+KVM: 0.000
+mistranslation: 0.000
+
+Qemu does not show all files on floppy or hard drive (MS DOS 6.22 guest)
+
+My host system is a raspberry pi model B 512MB. To start qemu I typed into lxterminal:
+  
+qemu-system-i386 -hda qemu.img -Fda Dos622-1.img -boot a
+
+Qemu version 1.7.0+dfsg-3 installed as package. The DOS disks were downloaded from winworldpc.com and if I mount them under Linux I see all the files, but on qemu I see the first 3 files only. The hard drive image I am using is a 30MB flat image created using bximage.
+
+Seems like you are using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks!
+
diff --git a/results/classifier/118/mistranslation-i386/1382477 b/results/classifier/118/mistranslation-i386/1382477
new file mode 100644
index 00000000..6a8fb4b3
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/1382477
@@ -0,0 +1,79 @@
+i386: 0.979
+device: 0.859
+mistranslation: 0.856
+socket: 0.797
+network: 0.788
+vnc: 0.782
+kernel: 0.709
+files: 0.702
+ppc: 0.699
+graphic: 0.660
+architecture: 0.645
+x86: 0.640
+virtual: 0.638
+semantic: 0.638
+register: 0.585
+PID: 0.537
+TCG: 0.537
+peripherals: 0.513
+assembly: 0.497
+arm: 0.493
+performance: 0.487
+permissions: 0.482
+risc-v: 0.479
+KVM: 0.476
+debug: 0.474
+hypervisor: 0.465
+boot: 0.453
+VMM: 0.412
+user-level: 0.411
+--------------------
+i386: 0.999
+x86: 0.991
+debug: 0.861
+files: 0.748
+kernel: 0.256
+hypervisor: 0.121
+TCG: 0.073
+device: 0.064
+user-level: 0.043
+virtual: 0.030
+VMM: 0.028
+register: 0.025
+architecture: 0.024
+semantic: 0.018
+PID: 0.018
+KVM: 0.012
+boot: 0.007
+assembly: 0.006
+performance: 0.005
+risc-v: 0.004
+ppc: 0.004
+network: 0.004
+socket: 0.004
+peripherals: 0.003
+graphic: 0.003
+permissions: 0.002
+vnc: 0.002
+mistranslation: 0.001
+arm: 0.000
+
+hw/i386/intel_iommu.c:902: wrong logical operator ?
+
+/home/dcb/qemu/trunk/qemu/hw/i386/intel_iommu.c:902:5: error: logical ‘and’ applied to non-boolean constant [-Werror=logical-op]
+     pvtd_as = s->address_spaces[VTD_SID_TO_BUS(source_id)];
+     ^
+
+$ fgrep VTD_SID_TO_BUS `find . -name \*.h -print`
+./include/hw/i386/intel_iommu.h:#define VTD_SID_TO_BUS(sid)         (((sid) >> 8) && 0xff)
+$ 
+
+Sounds to me like
+
+#define VTD_SID_TO_BUS(sid)         (((sid) >> 8) & 0xff)
+
+would be better.
+
+Fix has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1e06f131fd9a44dd4af
+
diff --git a/results/classifier/118/mistranslation-i386/1891749 b/results/classifier/118/mistranslation-i386/1891749
new file mode 100644
index 00000000..a1e95cb1
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/1891749
@@ -0,0 +1,68 @@
+mistranslation: 0.995
+i386: 0.989
+graphic: 0.898
+performance: 0.863
+device: 0.822
+architecture: 0.594
+semantic: 0.552
+network: 0.528
+user-level: 0.424
+kernel: 0.373
+vnc: 0.370
+risc-v: 0.360
+socket: 0.346
+boot: 0.308
+register: 0.294
+VMM: 0.290
+arm: 0.258
+debug: 0.229
+virtual: 0.207
+ppc: 0.206
+TCG: 0.201
+peripherals: 0.193
+assembly: 0.186
+PID: 0.182
+files: 0.178
+hypervisor: 0.175
+permissions: 0.169
+KVM: 0.093
+x86: 0.011
+--------------------
+virtual: 0.984
+i386: 0.983
+x86: 0.904
+user-level: 0.885
+TCG: 0.155
+hypervisor: 0.080
+graphic: 0.075
+debug: 0.074
+files: 0.045
+performance: 0.038
+device: 0.027
+register: 0.020
+semantic: 0.016
+network: 0.015
+PID: 0.013
+socket: 0.013
+peripherals: 0.010
+assembly: 0.010
+risc-v: 0.007
+VMM: 0.007
+architecture: 0.006
+boot: 0.005
+kernel: 0.005
+ppc: 0.003
+permissions: 0.002
+arm: 0.002
+KVM: 0.001
+mistranslation: 0.001
+vnc: 0.001
+
+CGA Mode 6 is only 100 pixels tall, when it's supposed to be 200
+
+I have written a program that used CGA Mode 6 (640x200 black and white). However qemu-system-i386 only displays the first 100 pixels, effectively limiting the resolution of mode 6 to 640x100. When running the same program on a real computer it uses the whole 640x200 pixels.
+
+Could you please provide a test program for this issue?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/mistranslation-i386/1919021 b/results/classifier/118/mistranslation-i386/1919021
new file mode 100644
index 00000000..2a278579
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/1919021
@@ -0,0 +1,77 @@
+i386: 0.987
+mistranslation: 0.966
+x86: 0.893
+device: 0.855
+network: 0.724
+architecture: 0.646
+graphic: 0.622
+TCG: 0.597
+virtual: 0.572
+socket: 0.571
+files: 0.545
+vnc: 0.529
+PID: 0.476
+VMM: 0.468
+semantic: 0.463
+performance: 0.437
+arm: 0.400
+boot: 0.394
+hypervisor: 0.386
+register: 0.371
+ppc: 0.356
+peripherals: 0.352
+kernel: 0.351
+risc-v: 0.349
+permissions: 0.242
+KVM: 0.208
+debug: 0.179
+assembly: 0.081
+user-level: 0.079
+--------------------
+i386: 0.898
+hypervisor: 0.738
+x86: 0.622
+debug: 0.465
+semantic: 0.221
+TCG: 0.150
+virtual: 0.110
+files: 0.072
+kernel: 0.068
+user-level: 0.047
+device: 0.016
+network: 0.012
+assembly: 0.009
+register: 0.009
+peripherals: 0.008
+performance: 0.008
+PID: 0.006
+architecture: 0.005
+socket: 0.004
+boot: 0.003
+graphic: 0.002
+risc-v: 0.002
+ppc: 0.001
+VMM: 0.001
+mistranslation: 0.001
+permissions: 0.001
+vnc: 0.001
+KVM: 0.001
+arm: 0.000
+
+Confuse error message in virtio_init_region_cache()
+
+The error message added in commit e45da653223 to virtio_init_region_cache()
+are somehow confuse:
+
+  qemu-system-i386: Cannot map used
+
+It would be helpful to more explicit string, including "virtio" prefix.
+
+
+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 'invalid' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/230
+
+
diff --git a/results/classifier/118/mistranslation-i386/2977 b/results/classifier/118/mistranslation-i386/2977
new file mode 100644
index 00000000..ca223eb2
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/2977
@@ -0,0 +1,71 @@
+i386: 0.970
+mistranslation: 0.880
+architecture: 0.870
+device: 0.805
+graphic: 0.698
+VMM: 0.672
+semantic: 0.643
+performance: 0.642
+vnc: 0.638
+x86: 0.597
+ppc: 0.557
+TCG: 0.520
+files: 0.513
+debug: 0.494
+risc-v: 0.493
+PID: 0.454
+virtual: 0.418
+socket: 0.416
+arm: 0.412
+network: 0.399
+register: 0.385
+boot: 0.377
+permissions: 0.371
+kernel: 0.360
+user-level: 0.287
+hypervisor: 0.210
+assembly: 0.188
+peripherals: 0.103
+KVM: 0.095
+--------------------
+i386: 0.967
+x86: 0.926
+debug: 0.558
+hypervisor: 0.450
+user-level: 0.135
+TCG: 0.120
+virtual: 0.080
+files: 0.065
+kernel: 0.051
+performance: 0.046
+network: 0.037
+register: 0.026
+semantic: 0.020
+PID: 0.017
+architecture: 0.016
+device: 0.010
+VMM: 0.007
+assembly: 0.007
+boot: 0.005
+socket: 0.005
+risc-v: 0.003
+ppc: 0.003
+vnc: 0.002
+peripherals: 0.002
+graphic: 0.001
+KVM: 0.001
+permissions: 0.001
+mistranslation: 0.001
+arm: 0.000
+
+QEMU SVM VMCB exit_code is uint32_t when AMD spec requires uint64_t
+Description of problem:
+QEMU's SVM implementation incorrectly uses a 32-bit parameter for the exit code in the `cpu_vmexit` function, despite the AMD SVM specification requiring a 64-bit exit code field in the VMCB (Virtual Machine Control Block).
+
+I think the issue is in `target/i386/svm.c` in the `cpu_vmexit` function.
+
+The `exit_code` parameter is declared as `uint32_t` but should be `uint64_t` according to the AMD SVM specification. This causes exit codes to be truncated to 32 bits, resulting in values like 0xffff_ffff instead of the expected 0xffff_ffff_ffff_ffff.
+Steps to reproduce:
+
+Additional information:
+[this](https://stackoverflow.com/questions/79632531/qemu-svm-vmcb-exit-code-is-uint32-t-when-amd-spec-requires-uint64-t?noredirect=1#comment140448815_79632531) question I posted on stack overflow
diff --git a/results/classifier/118/mistranslation-i386/996798 b/results/classifier/118/mistranslation-i386/996798
new file mode 100644
index 00000000..9bf4e58f
--- /dev/null
+++ b/results/classifier/118/mistranslation-i386/996798
@@ -0,0 +1,78 @@
+mistranslation: 0.863
+device: 0.842
+virtual: 0.840
+i386: 0.833
+hypervisor: 0.825
+architecture: 0.792
+vnc: 0.726
+register: 0.716
+graphic: 0.663
+performance: 0.625
+socket: 0.583
+semantic: 0.582
+network: 0.552
+ppc: 0.546
+risc-v: 0.459
+x86: 0.426
+boot: 0.402
+permissions: 0.386
+VMM: 0.378
+kernel: 0.377
+PID: 0.346
+files: 0.296
+arm: 0.277
+TCG: 0.240
+debug: 0.233
+peripherals: 0.190
+assembly: 0.119
+user-level: 0.111
+KVM: 0.039
+--------------------
+x86: 0.990
+i386: 0.984
+virtual: 0.900
+hypervisor: 0.697
+debug: 0.141
+files: 0.054
+kernel: 0.050
+register: 0.049
+architecture: 0.045
+TCG: 0.040
+performance: 0.036
+PID: 0.034
+user-level: 0.015
+assembly: 0.015
+device: 0.012
+semantic: 0.011
+risc-v: 0.006
+boot: 0.005
+network: 0.005
+VMM: 0.002
+ppc: 0.002
+socket: 0.002
+peripherals: 0.001
+graphic: 0.001
+vnc: 0.001
+KVM: 0.000
+permissions: 0.000
+mistranslation: 0.000
+arm: 0.000
+
+Incorrect order of task switching
+
+In Intel  specifications (http://download.intel.com/design/processor/manuals/253668.pdf 7.3), we can see:
+
+    8. Saves the state of the current (old) task in the current task’s TSS. 
+
+…
+
+   11. Loads the task register with the segment selector and descriptor for the new  task's TSS.
+
+But, in QEMU code (https://raw.github.com/qemu/QEMU/v1.0/target-i386/op_helper.c :375), the order is reversed: TSS registers & segments loads BEFORE save old task state.
+
+Some bug in VirtualBox: https://www.virtualbox.org/ticket/10532
+
+Is problem still reproducable with the latest version of QEMU, or has it been fixed nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+