13 files changed, 554 insertions, 0 deletions
diff --git a/results/classifier/108/other/127 b/results/classifier/108/other/127
new file mode 100644
index 000000000..33a0ad6ba
--- /dev/null
+++ b/results/classifier/108/other/127
@@ -0,0 +1,16 @@
+network: 0.642
+device: 0.595
+debug: 0.577
+boot: 0.469
+performance: 0.451
+semantic: 0.357
+graphic: 0.299
+permissions: 0.110
+files: 0.052
+socket: 0.047
+other: 0.033
+PID: 0.032
+vnc: 0.023
+KVM: 0.014
+
+linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8")
diff --git a/results/classifier/108/other/1270 b/results/classifier/108/other/1270
new file mode 100644
index 000000000..fd4419e70
--- /dev/null
+++ b/results/classifier/108/other/1270
@@ -0,0 +1,29 @@
+graphic: 0.885
+device: 0.865
+performance: 0.558
+network: 0.425
+KVM: 0.417
+PID: 0.372
+vnc: 0.326
+semantic: 0.274
+boot: 0.204
+debug: 0.167
+permissions: 0.054
+other: 0.040
+socket: 0.035
+files: 0.023
+
+Guest freezes if memory backing using memfd/shared/
+Description of problem:
+Guest VM freezes with the following memory backing is set. Required to for virtiofs, but just setting the following the guest will freeze in around 2hours, no logs or errors generate.
+
+  <memoryBacking>
+    <source type='memfd'/>
+    <access mode='shared'/>
+  </memoryBacking>
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/108/other/1270397 b/results/classifier/108/other/1270397
new file mode 100644
index 000000000..aa3834293
--- /dev/null
+++ b/results/classifier/108/other/1270397
@@ -0,0 +1,92 @@
+other: 0.969
+permissions: 0.964
+graphic: 0.963
+semantic: 0.954
+debug: 0.940
+performance: 0.936
+device: 0.920
+boot: 0.916
+network: 0.904
+PID: 0.903
+vnc: 0.892
+socket: 0.874
+KVM: 0.858
+files: 0.835
+
+Systemd segfaults after live migration
+
+After live migrating my virtual machine it panics because of segmentation fault in systemd (see attachment). 
+
+Software used (on archlinux):
+qemu 1.7.0-1
+libvirt 1.2.0-1
+linux 3.12.7-1
+
+This is configuration of this VM:
+<domain type='kvm'>
+  <name>vbroker</name>
+  <uuid>455c9c62-10a6-11e3-a7f2-441ea153aac8</uuid>
+  <description>455c9c62-10a6-11e3-a7f2-441ea153aac8</description>
+  <memory unit='KiB'>6291456</memory>
+  <currentMemory unit='KiB'>6291456</currentMemory>
+  <vcpu placement='static'>4</vcpu>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-1.7'>hvm</type>
+    <boot dev='cdrom'/>
+    <bootmenu enable='no'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+  </features>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-kvm</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='none'/>
+      <source file='/var/lib/libvirt/images/archipel/drives/455c9c62-10a6-11e3-a7f2-441ea153aac8/vbroker.qcow2'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'/>
+    <interface type='bridge'>
+      <mac address='de:ad:fb:8e:17:c2'/>
+      <source bridge='br0'/>
+      <model type='virtio'/>
+      <filterref filter='clean-traffic'>
+        <parameter name='IP' value='10.0.0.2'/>
+      </filterref>
+      <bandwidth>
+      </bandwidth>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <input type='tablet' bus='usb'/>
+    <input type='mouse' bus='ps2'/>
+    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
+    <video>
+      <model type='cirrus' vram='9216' heads='1'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </memballoon>
+  </devices>
+</domain>
+
+
+
+Hi Mateusz,
+  How are you migrating?  If you are using the compress/xbzrle option, try turning it off and see if that helps, there are some corruption fixes for xbzrle in 2.0.0.
+
+Dave
+
+Can you still reproduce this issue with the latest version of QEMU and libvirt?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1272252 b/results/classifier/108/other/1272252
new file mode 100644
index 000000000..1a9523c62
--- /dev/null
+++ b/results/classifier/108/other/1272252
@@ -0,0 +1,46 @@
+performance: 0.758
+graphic: 0.727
+device: 0.696
+other: 0.694
+semantic: 0.668
+network: 0.575
+PID: 0.539
+socket: 0.523
+files: 0.492
+permissions: 0.462
+vnc: 0.354
+debug: 0.332
+boot: 0.306
+KVM: 0.245
+
+qemu-img ftp/http convert
+
+Converting images with ftp or http as source could be done a lot faster. The way it works now (qemu 1.7.50) is significantly slower than the optimal way. 
+
+FTP - how it works now
+1. Connect and login to ftp-server. Ask for size of file.
+2. Get a chunk of data using rest+retr
+3. Goto step 1 again in a loop until all data is retrieved
+
+FTP - better solution
+1. Connect and login to ftp-server. Dont ask for size of file.
+2. Retrieve all remaining data
+3. Goto step 1 again if disconnected/io error (max NN errors etc)
+
+
+Http - how it works now
+1. Connect to webserver and ask for size of file / http HEAD.
+2. Get a chunk of data using http Range.
+3. Goto step 1 again in a loop until all data is retrieved.
+
+Http - better solution
+1. Connect to webserver.
+2. Retrieve all remaining data.
+3. Goto step 1 again if disconnected/io error (max NN errors).
+
+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 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/108/other/1272796 b/results/classifier/108/other/1272796
new file mode 100644
index 000000000..97baddf48
--- /dev/null
+++ b/results/classifier/108/other/1272796
@@ -0,0 +1,41 @@
+performance: 0.825
+graphic: 0.810
+boot: 0.802
+device: 0.787
+semantic: 0.726
+other: 0.690
+PID: 0.661
+files: 0.657
+socket: 0.631
+vnc: 0.533
+permissions: 0.474
+KVM: 0.449
+network: 0.421
+debug: 0.326
+
+Windows 98 First Edition emulation problems
+
+System: Debian SID x86 with latest updates
+
+1) QEMU compiled from latest main GIT branch (and 1.7 stable version)
+./configure options: ./configure --enable-sdl --target-list=i386-softmmu --cpu=i686 --audio-drv-list=alsa
+
+When you try to boot Windows 98 First Edition (Italian), it does not simply boot. It stays on booting screen. 
+If you try to install, the installation goes flawless, but when it boots it freeze.
+
+I am launching VM with this: qemu-system-i386 -hda main.img -cpu pentium -m 256 -fda floppy1.img -boot c -soundhw gus -vga cirrus
+
+I have tried with -M option "pc-i440fx-1.6" since 1.6 have no problems with the booting of Win98, but nothing. No fix found.
+
+2) QEMU 1.6.2 (same compile and launching options)
+gus soundboard seems not recognized even with real dos drivers (tried to install theme into real dos mode).
+with SoundBlaster 16 i have following error: WARNING: I/O thread spun for 1000 iterations, making the emulation impossible (too slow, and sound is stuttering) . Tried to compile with oss and sdl option on audio-drv-list but no fix found.
+
+Any ideas? thank you
+
+Even with Windows 98 SE (English and Italian) still not working. Got some ideas?
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1273 b/results/classifier/108/other/1273
new file mode 100644
index 000000000..bc5970df1
--- /dev/null
+++ b/results/classifier/108/other/1273
@@ -0,0 +1,16 @@
+device: 0.897
+debug: 0.589
+graphic: 0.318
+performance: 0.306
+other: 0.274
+network: 0.221
+vnc: 0.149
+semantic: 0.129
+boot: 0.078
+permissions: 0.035
+PID: 0.035
+socket: 0.029
+files: 0.007
+KVM: 0.001
+
+QEMU log problem
diff --git a/results/classifier/108/other/1274 b/results/classifier/108/other/1274
new file mode 100644
index 000000000..8f17ff718
--- /dev/null
+++ b/results/classifier/108/other/1274
@@ -0,0 +1,47 @@
+graphic: 0.769
+debug: 0.743
+device: 0.622
+performance: 0.508
+PID: 0.470
+boot: 0.426
+semantic: 0.353
+permissions: 0.316
+vnc: 0.288
+socket: 0.253
+other: 0.246
+KVM: 0.184
+network: 0.180
+files: 0.153
+
+Cannot debug init using "qemu -s -S" if init is compiled dynamically or if kvm is enabled
+Description of problem:
+I'm trying to connect from host to init process running in guest. I'm using this guide: https://qemu-project.gitlab.io/qemu/system/gdb.html . Everything works well, but there is two problems:
+1. Debugging stops to work if I add "-enable-kvm"
+2. Debugging stops to work if I remove "-static" when compiling init
+Steps to reproduce:
+I have absolutely fresh Debian sid system (as of 2022-10-22). I create the following file on it:
+```c
+#include <stdio.h>
+
+int
+main ()
+{
+  printf ("a\n");
+  printf ("b\n");
+  for (;;);
+}
+```
+
+Then I compile it so: `gcc -static -g a.c`. Result is saved as `/root/a.out`. Then I run `sync; echo 3 > /proc/sys/vm/drop_caches; sync` to make sure this `/root/a.out` actually got to disk.
+
+Then I start the host system inside of qemu using well-known `-snapshot /dev/sda` trick. Exact command is here:
+
+```bash
+qemu-system-x86_64 -daemonize -m 300M -s -S -kernel /vmlinuz -initrd /initrd.img -snapshot -append "root=/dev/sda init=/root/a.out" -drive file=/dev/sda,format=raw
+```
+
+(As you guessed, my disk has no partitions, it directly stores ext4 filesystem.)
+
+Then I type on host `gdb ./a.out`. And then inside of gdb I type `target remote localhost:1234`, then `br 7` (line 7 is `printf ("b\n")`, then `c`. Then guest OS boots and reaches init (i. e. `/root/a.out`). And then gdb actually pauses on line 7. I. e. everything works!
+
+But if I add `-enable-kvm` to qemu command line OR remove `-static` from gcc command line, then breakpoint doesn't work, i. e. gdb doesn't pause on breakpoint, the execution continues and the execution fails to infinite loop.
diff --git a/results/classifier/108/other/1274170 b/results/classifier/108/other/1274170
new file mode 100644
index 000000000..51d797695
--- /dev/null
+++ b/results/classifier/108/other/1274170
@@ -0,0 +1,27 @@
+device: 0.744
+graphic: 0.650
+semantic: 0.517
+network: 0.431
+other: 0.396
+socket: 0.332
+files: 0.302
+performance: 0.289
+boot: 0.262
+PID: 0.257
+vnc: 0.216
+permissions: 0.199
+debug: 0.198
+KVM: 0.034
+
+qemu window hides in the background on osx
+
+When launching qemu on OSX (10.8.5), the window comes up in the background.  A bit of googling shows that the addition of [NSApp activateIgnoringOtherApps:YES]; before the [NSApp run]; in main fixes this.
+
+Looks like such a line has been added with this commit here:
+http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=43227af88a36faed
+Is the latest version of QEMU now working as expected?
+
+This seems to only affect fullscreen mode, so if that's the case, I don't see it as resolved.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1275 b/results/classifier/108/other/1275
new file mode 100644
index 000000000..f5aeb7c30
--- /dev/null
+++ b/results/classifier/108/other/1275
@@ -0,0 +1,24 @@
+device: 0.884
+graphic: 0.700
+performance: 0.613
+vnc: 0.535
+network: 0.535
+debug: 0.468
+socket: 0.373
+PID: 0.329
+files: 0.264
+semantic: 0.193
+boot: 0.127
+permissions: 0.086
+other: 0.047
+KVM: 0.001
+
+javac command stuck forever in qemu vm which does not use hardware virtualization
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/108/other/1276879 b/results/classifier/108/other/1276879
new file mode 100644
index 000000000..b46fa06a0
--- /dev/null
+++ b/results/classifier/108/other/1276879
@@ -0,0 +1,146 @@
+permissions: 0.777
+semantic: 0.771
+other: 0.770
+debug: 0.750
+device: 0.723
+graphic: 0.721
+PID: 0.717
+performance: 0.697
+KVM: 0.696
+vnc: 0.664
+network: 0.605
+boot: 0.599
+socket: 0.582
+files: 0.538
+
+lots of dma command 10, 14 not supported
+
+Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0.
+In the terminal that started QEMU, there are a lot of
+    dma: command 10 not supported
+and 
+    dma: command 14 not supported
+messages.  When the installation of NeXTSTEP gets to
+'preparing disk for nextstep installation', there are a lot
+of messages that ATA command c5 failed and other info.
+The result is a failed installation.
+
+Is this a bug in QEMU?  Is there a workaround, e.g. by
+disabling DMA altogether?
+
+thank you
+
+Getting the same result in QEMU 1.6.2.  NeXT setup is reporting
+'interrupt timeout, cmd: 0xc5', ATA command c5 failed,
+resetting drives.
+This repeats until it gives up.
+
+
+On 02/06/14 02:14, tyler knosis wrote:
+> Public bug reported:
+> 
+> Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0.
+> In the terminal that started QEMU, there are a lot of
+>     dma: command 10 not supported
+> and 
+>     dma: command 14 not supported
+> messages.
+
+These correspond to
+
+  CMD_CYCLIC_PRIORITY
+
+and
+
+  CMD_CYCLIC_PRIORITY | CMD_BLOCK_CONTROLLER
+
+in write_cont() [hw/dma/i8257.c]. They are not supported (see
+CMD_NOT_SUPPORTED in the same file).
+
+> When the installation of NeXTSTEP gets to
+> 'preparing disk for nextstep installation', there are a lot
+> of messages that ATA command c5 failed and other info.
+> The result is a failed installation.
+
+0xC5 is WIN_MULTWRITE ("write sectors using multiple mode"), and it
+seems to hook into DMA.
+
+> Is this a bug in QEMU?
+
+Probably not, it's more likely "incomplete" DMA emulation ("lack of
+support").
+
+> Is there a workaround, e.g. by
+> disabling DMA altogether?
+
+It's worth a try I guess, if you can figure out a way how to do that.
+FWIW, ide_identify() appears to report unconditional support for:
+- single word dma0-2
+- mdma0-2
+- udma5
+
+(I have no clue about IDE or DMA btw.)
+
+Laszlo
+
+
+p.s.  I tried Bochs 2.6.2, and it is not stuck at the same place.  Did qemu take the bochs bios
+and change anything regarding the IDE drives?
+
+
+Successfully installed NextStep in bochs, but not qemu.
+
+Having same problem with OpenStep 4.2 in qemu.
+
+
+http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg00889.html
+
+So, Zoltan pointed to two patches.  I applied the first (v8-06-10-i8259-fix.....),
+but the second patches a file that is not in version 1.7.0.
+
+With the one patch, I am now able to get past the step where it crapped out
+before.  The dma messages are still there, but it seems that they can be ignored.
+NextStep can now install its basic system onto a file.
+
+Thank you for the help so far.
+
+Now, I get to the point when NeXTStep want me to click on something to configure
+the new system, but QEMU is not grabbing the mouse.  After this step, it will install
+the remainder of the system + apps.
+
+I have a USB mouse on a x86_64 linux machine, and QEMU 1.7.0.  This is the
+command line I used:
+qemu-system-x86_64 -hda x.img -fda f.img -cdrom cd.img
+
+I have tried ctl-alt (both sides of the keyboard) to no avail.
+
+
+The other patch is for KVM. Here's a way to build a patched kvm module (I did not test it):
+http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_0_kvm_kmod_build
+
+A click in the window should be enough to grab the mouse. If it's not working it may be that NeXTSTEP is using a different driver than what QEMU emulates. Since NeXTSTEP is quite old you may have better luck with a serial mouse emulation such as msmouse or make sure a PS/2 mouse driver is selected in NeXTSTEP (it may not autodetect it).
+
+
+No luck with msmouse.  NextStep assumes a PS/2 mouse, I believe,
+which is what QEMU emulates by default.  In bochs, the mouse does
+work in NextStep.  Do you know if bochs emulates the PS/2 mouse
+by default?
+
+
+I don't know about Bochs but here's another page with resources on running OPENSTEP on a VM:
+http://www.zebpedersen.co.uk/?p=126
+The VMWare drivers (both svga and mouse) should work with QEMU too but I don't know if they are compatible with NeXTSTEP.
+Now I remember there was some problem with mouse emulation with the PS/2 or serial driver also on VMWare which made the mouse pointer jump around and then freeze. This may also happen with QEMU but it was never debugged AFAIK.
+
+thank you.  Will keep at it.
+
+
+Mouse not working in WinXP with QEMU either.
+But it is working with bochs (same disk image).
+
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1277 b/results/classifier/108/other/1277
new file mode 100644
index 000000000..45ba9919f
--- /dev/null
+++ b/results/classifier/108/other/1277
@@ -0,0 +1,16 @@
+performance: 0.856
+graphic: 0.792
+device: 0.782
+other: 0.634
+debug: 0.620
+PID: 0.612
+KVM: 0.541
+vnc: 0.529
+socket: 0.454
+network: 0.440
+boot: 0.424
+semantic: 0.371
+permissions: 0.353
+files: 0.193
+
+two instructions has executed twice
diff --git a/results/classifier/108/other/1278166 b/results/classifier/108/other/1278166
new file mode 100644
index 000000000..eb3dab678
--- /dev/null
+++ b/results/classifier/108/other/1278166
@@ -0,0 +1,23 @@
+graphic: 0.632
+device: 0.532
+other: 0.426
+files: 0.352
+semantic: 0.352
+vnc: 0.207
+socket: 0.205
+network: 0.188
+boot: 0.163
+permissions: 0.159
+debug: 0.157
+performance: 0.137
+PID: 0.131
+KVM: 0.007
+
+Last commit to exec.c causes BSOD installing WinXP on i386-softmmu
+
+The last commit to exec.c (360e607b88a23d378f6efaa769c76d26f538234d), causes a BSOD when trying to install a 32bit Windows XP SP-3 image using the pure emulation version of i386-softmmu. A checkout of the previous version of the file (commited in 0169c511554cb0014a00290b0d3d26c31a49818f) solves the problem. Nevertheless, this last commit was intented to solve a BSOD when Xen was used as a hypervisor.
+
+Can you still reproduce this issue with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1279257 b/results/classifier/108/other/1279257
new file mode 100644
index 000000000..4649292b1
--- /dev/null
+++ b/results/classifier/108/other/1279257
@@ -0,0 +1,31 @@
+device: 0.653
+socket: 0.650
+vnc: 0.576
+network: 0.565
+graphic: 0.498
+semantic: 0.448
+other: 0.419
+files: 0.372
+permissions: 0.368
+performance: 0.367
+KVM: 0.347
+PID: 0.328
+debug: 0.291
+boot: 0.270
+
+[hw/scsi/scsi-bus.c:910]: (style) Expression '(X & 0x4) == 0x1' is always false.
+
+Source code is
+
+       } else if ((buf[1] & 4) == 1) {
+
+Suggest code rework. I found this bug by running
+static analyser cppcheck over the source code.
+
+I also checked the latest code on the web and the
+bug exists there also.
+
+Looks like this has been fixed here already:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7ef8cf9a0861b6f67f5e
+
+