3 files changed, 218 insertions, 0 deletions
diff --git a/results/classifier/108/other/1162 b/results/classifier/108/other/1162
new file mode 100644
index 00000000..cdb0dc08
--- /dev/null
+++ b/results/classifier/108/other/1162
@@ -0,0 +1,27 @@
+graphic: 0.918
+vnc: 0.896
+network: 0.885
+device: 0.816
+KVM: 0.712
+PID: 0.679
+semantic: 0.540
+debug: 0.521
+socket: 0.455
+files: 0.339
+boot: 0.287
+permissions: 0.152
+other: 0.132
+performance: 0.124
+
+`./configure` gives `big/little test failed` error when attempting to statically link on Fedora 36
+Description of problem:
+I'm having trouble attempting to build the QEMU System emulator statically linked. The error `./configure` gives `big/little test failed` with nothing else. I couldn't find any information relating to this. I'm not sure where to start fixing this. If anyone can help me with this, thanks!
+Steps to reproduce:
+1. `git clone https://gitlab.com/qemu-project/qemu.git`
+2. `cd qemu`
+3. `git submodule init`
+4. `git submodule update`
+5. `./configure --enable-kvm --enable-vnc --enable-vhost-net --enable-avx2 --enable-avx512f --target-list=x86_64-softmmu --static`
+6. Observe build error
+Additional information:
+
diff --git a/results/classifier/108/other/1162227 b/results/classifier/108/other/1162227
new file mode 100644
index 00000000..c77a6e42
--- /dev/null
+++ b/results/classifier/108/other/1162227
@@ -0,0 +1,45 @@
+graphic: 0.897
+other: 0.847
+permissions: 0.843
+semantic: 0.843
+performance: 0.773
+socket: 0.766
+network: 0.753
+files: 0.736
+PID: 0.724
+debug: 0.713
+KVM: 0.671
+device: 0.662
+boot: 0.651
+vnc: 0.604
+
+Mouse works badly when connecting to host via vnc
+
+Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc.
+Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest.
+
+I saw this bug in the following configurations:
+* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line:
+qemu-system-x86_64 --enable-kvm -m 2048  -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow
+* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line:
+qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda
+* A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line:
+qemu-system-x86_64 --enable-kvm -m 2048  -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow
+
+Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host".
+
+Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work".
+
+I tried to reproduce this bug using lastest stable version (1.4.0) and master (5e3a0f418c4d57399778cee0b55aebfb663b6425).
+This versions seem to add "-usbdevice tablet" by default (and this is very good). But I think that if guest OS doesn't support tablet device then bug will still appear. So, I added option "-usbdevice mouse" to simulate this situation. And bug really appeared (i. e. mouse disappeared). So, please fix it or document it.
+
+Configurations:
+* A: Ubuntu precise 64-bit, x11vnc 0.9.12, Qemu 1.4.0, C: Debian squeeze 64-bit, xvnc4viewer 4.1.1, B: Ubuntu precise 64-bit, command line:
+/opt/qemu-1.4.0/bin/qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -drive cache=none,file=/dev/sda -net none -usbdevice mouse
+* A: Ubuntu precise 64-bit, x11vnc 0.9.12, Qemu 5e3a0f418c4d57399778cee0b55aebfb663b6425, C: Debian squeeze 64-bit, xvnc4viewer 4.1.1, B: Ubuntu precise 64-bit, command line:
+/opt/qemu-5e3a0f418c4d57399778cee0b55aebfb663b6425/bin/qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -drive cache=none,file=/dev/sda -net none -usbdevice mouse
+
+Same for -vnc option (i. e. pointers was not synced when using -usbdevice mouse)
+
+As you mentioned already, the solution is to use an USB tablet instead of a mouse device, and as far as I can see, it is also mentioned in the documentation of the "-vnc" parameter, so I'm closing this ticket now...
+
diff --git a/results/classifier/108/other/1162644 b/results/classifier/108/other/1162644
new file mode 100644
index 00000000..ba446810
--- /dev/null
+++ b/results/classifier/108/other/1162644
@@ -0,0 +1,146 @@
+vnc: 0.888
+permissions: 0.856
+KVM: 0.850
+other: 0.842
+performance: 0.841
+device: 0.840
+boot: 0.823
+debug: 0.800
+graphic: 0.792
+files: 0.787
+socket: 0.787
+semantic: 0.782
+network: 0.777
+PID: 0.738
+
+qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base()
+
+Description:
+When QEMU tries to boot with a usb 3.0 tablet (xhci) on a Raring ringtail box (QEMU package1.4.0+dfsg-1expubuntu4)  it will crash soon afterwards:
+
+qemu-system-x86_64: /build/buildd/qemu-1.4.0+dfsg/hw/usb/core.c:552: usb_packet_setup: Assertion `p->iov.iov != ((void *)0)' failed.
+
+Component:
+qemu-system -> 1.4.0+dfsg-1expubuntu4
+
+Ubuntu Version:
+
+Description:	Ubuntu Raring Ringtail (development branch)
+Release:	13.04
+
+Steps to reproduce it:
+
+I met this bug while running the virt-test suite
+
+https://github.com/autotest/virt-test
+
+Instructions to install and run it can be seen on the README file
+
+https://github.com/autotest/virt-test#readme
+
+After the suite is set, it can be reproduced on a raring (13.04) simply by running:
+
+./run -t qemu --tests usb.usb_reboot.usb_tablet.xhci
+
+Command line:
+
+23:52:42 INFO | Running qemu command (reformatted):
+/usr/bin/kvm \
+    -S \
+    -name 'virt-tests-vm1' \
+    -nodefaults \
+    -chardev socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130331-233911-ndvUEvrV,server,nowait \
+    -mon chardev=hmp_id_hmp1,mode=readline \
+    -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130331-233911-ndvUEvrV,server,nowait \
+    -device isa-serial,chardev=serial_id_serial1 \
+    -chardev socket,id=seabioslog_id_20130331-233911-ndvUEvrV,path=/tmp/seabios-20130331-233911-ndvUEvrV,server,nowait \
+    -device isa-debugcon,chardev=seabioslog_id_20130331-233911-ndvUEvrV,iobase=0x402 \
+    -device ich9-usb-uhci1,id=usb1 \
+    -device nec-usb-xhci,id=usbtest \
+    -drive file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0 \
+    -device virtio-blk-pci,drive=virtio0,bootindex=1 \
+    -device virtio-net-pci,netdev=idumV1TE,mac='9a:c0:c1:c2:c3:c4',id='idmN7iHv' \
+    -netdev user,id=idumV1TE,hostfwd=tcp::5000-:22 \
+    -m 1024 \
+    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
+    -cpu 'SandyBridge' \
+    -M pc \
+    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
+    -device usb-tablet,id=usb-testdev,bus=usbtest.0,port=1 \
+    -vnc :0 \
+    -vga std \
+    -rtc base=utc,clock=host,driftfix=none  \
+    -boot order=cdn,once=c,menu=off  \
+    -enable-kvm
+
+ProblemType: Crash
+DistroRelease: Ubuntu 13.04
+Package: qemu-system-x86 1.4.0+dfsg-1expubuntu4
+ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4
+Uname: Linux 3.8.0-15-generic x86_64
+ApportVersion: 2.9.2-0ubuntu5
+Architecture: amd64
+Date: Sun Mar 31 23:52:46 2013
+EcryptfsInUse: Yes
+ExecutablePath: /usr/bin/qemu-system-x86_64
+InstallationDate: Installed on 2013-03-31 (0 days ago)
+InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
+MarkForUpload: True
+ProcEnviron:
+ TERM=dumb
+ PATH=(custom, no user)
+ XDG_RUNTIME_DIR=<set>
+ LANG=en_US.UTF-8
+ SHELL=/bin/bash
+Signal: 6
+SourcePackage: qemu
+StacktraceTop:
+ raise () from /lib/x86_64-linux-gnu/libc.so.6
+ abort () from /lib/x86_64-linux-gnu/libc.so.6
+ ?? () from /lib/x86_64-linux-gnu/libc.so.6
+ __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
+ ?? ()
+Title: qemu-system-x86_64 crashed with SIGABRT in raise()
+UpgradeStatus: Upgraded to raring on 2013-03-31 (0 days ago)
+UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thanks for reporting this bug, I will try to reproduce it, and check whether upstream git head has the same bug.
+
+I can't reproduce this on a clean raring system, which has the same qemu version as your quantal system.
+
+Is it possible for you to test on a clean raring system?
+
+What is your libvirt package version?
+
+It doesn't get any cleaner than this. I've installed the box with 12.10, immediately followed by upgrade to 13.04. What seems to be going on is that the issue is not 100% reproducible (I tried today with the same setup and could not reproduce it).
+
+Moreover, what really matters here is the qemu/kernel version, and nothing else.
+
+Libvirt version is 1.0.2-0ubuntu10. I did compile the latest git master and so far I could not reproduce it either.
+
+I could just reproduce it on Fedora 19 qemu-kvm version (which is 1.4.0) and qemu.git master. So the issue is not 100% reproducible, but it can be seen on qemu.git master and therefore, downstream packages such as the ones found on Ubuntu and Fedora, for example.
+
+Ok, thanks - i did run it 3 or 4 times.  How often would you say it fails for you?
+
+I will mark this as affecting the upstream qemu project based on comment #10.
+
+On my F19 box, it's failing about 2/3 of the attempts. What is funny is that on the Ubuntu 13.04 box, I can't get the problem reproduced anymore, for some reason beyond me.
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+Sure, please close it.
+