4 files changed, 207 insertions, 0 deletions
diff --git a/results/classifier/108/other/584 b/results/classifier/108/other/584
new file mode 100644
index 000000000..103a13739
--- /dev/null
+++ b/results/classifier/108/other/584
@@ -0,0 +1,58 @@
+device: 0.886
+graphic: 0.866
+PID: 0.823
+debug: 0.787
+performance: 0.769
+semantic: 0.726
+vnc: 0.713
+other: 0.692
+network: 0.658
+boot: 0.632
+socket: 0.595
+permissions: 0.587
+files: 0.336
+KVM: 0.244
+
+qemu-system-ppc: extra IPI interrupt on core0
+Description of problem:
+When I try to emit an IPI interrupt from core0 to another core via the MPIC controller(IPIDR1—Interprocessor interrupt dispatch register 1), core0 itself generates an unwanted IPI interrupt.
+Steps to reproduce:
+1. Prepare ISR routine, something like:
+
+    void ipi_handler (void)
+    {
+	int core_id = CORE_ID_GET(); 
+        myprintf("\n IPI interrupt triggered on core:%d\n",core_id);
+    }
+2. Create a task and bind it to core0. This task is mainly to write the MPIC controller to emit IPI interrupts to other cores.
+    MPIC_REG_WRITE(MPIC_BASE + IPIDR1, **0xe**);
+
+3. run the test task
+Additional information:
+/* Below test was tested on Qemu6.1 */
+
+IPI interrupts are emitted by core:0
+
+**IPI interrupt triggered on core:0** /* it's a bug, it should not trigger on core 0. */
+
+IPI interrupt triggered on core:1
+
+IPI interrupt triggered on core:2
+
+IPI interrupt triggered on core:3
+
+
+This bug only occurs when "emitting an IPIDR1 interrupt from **core0**".
+
+------------
+
+
+/* Below test was tested on real board(fsl_p4080ds) */
+
+IPI interrupts are emitted by core:0
+
+IPI interrupt triggered on core:1
+
+IPI interrupt triggered on core:2
+
+IPI interrupt triggered on core:3
diff --git a/results/classifier/108/other/584146 b/results/classifier/108/other/584146
new file mode 100644
index 000000000..79d12747e
--- /dev/null
+++ b/results/classifier/108/other/584146
@@ -0,0 +1,27 @@
+files: 0.816
+device: 0.731
+vnc: 0.536
+network: 0.491
+socket: 0.424
+graphic: 0.403
+semantic: 0.403
+debug: 0.311
+performance: 0.306
+boot: 0.296
+other: 0.227
+PID: 0.215
+permissions: 0.169
+KVM: 0.048
+
+Virtual fat breaks with -snapshot
+
+When using fat emulation together with snapshot, qemu fails to find the directory for the fat "filesystem".
+
+See Debian bug#504049, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504049 and discussion on qemu-devel with Kevin Wolf, http://marc.info/?t=126850802800001 for details.
+
+There's a workaround for this bug: when using full path for fat:/dir/name it works.
+
+Can you still reproduce this issue with the latest version of QEMU? If so, could you please provide a proper command line that triggers this problem?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/584514 b/results/classifier/108/other/584514
new file mode 100644
index 000000000..2602c2648
--- /dev/null
+++ b/results/classifier/108/other/584514
@@ -0,0 +1,51 @@
+KVM: 0.913
+device: 0.664
+performance: 0.605
+graphic: 0.585
+semantic: 0.455
+other: 0.422
+socket: 0.312
+permissions: 0.287
+PID: 0.269
+network: 0.264
+vnc: 0.210
+debug: 0.169
+boot: 0.144
+files: 0.106
+
+Qemu-KVM 0.12.4 Guest entered Paused State
+
+I recently had a 0.12.4 qemu-kvm with a debian lenny guest which occasionally paused.
+
+There was no memory exhaustion as suggested earlier.
+
+qemu-kvm send the following output::
+
+VM internal error. Suberror: 1
+rax 0000000000000100 rbx ffff880017585bc0 rcx 00007f84c6d5b000 rdx 0000000000000001
+rsi 0000000000000000 rdi ffff88001d322dec rsp ffff88001e133e88 rbp ffff88001e133e88
+r8  0000000001f25bc2 r9  0000000000000007 r10 00007f84c6b4d97b r11 0000000000000206
+r12 ffff88001d322dec r13 ffff88001d322de8 r14 0000000000000001 r15 0000000000000000
+rip ffffffff81039719 rflags 00010092
+cs 0010 (00000000/ffffffff p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0)
+ds 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+es 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+ss 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
+fs 0000 (7f84c6d53700/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+gs 0000 (ffff880001d00000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+tr 0040 (ffff880001d13780/00002087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
+ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+gdt ffff880001d04000/7f
+idt ffffffff8195e000/fff
+cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501
+emulation failure, check dmesg for details
+
+Unfortunately, I found nothing in syslog or dmesg
+
+How about the qemu process，in which state？ will it be blocking？ 
+
+
+QEMU 0.12 is pretty old nowadays - is this issue still reproducible 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/584516 b/results/classifier/108/other/584516
new file mode 100644
index 000000000..ff16e20cf
--- /dev/null
+++ b/results/classifier/108/other/584516
@@ -0,0 +1,71 @@
+permissions: 0.888
+files: 0.885
+debug: 0.879
+other: 0.876
+network: 0.852
+graphic: 0.843
+device: 0.840
+vnc: 0.836
+performance: 0.835
+socket: 0.831
+KVM: 0.829
+semantic: 0.794
+boot: 0.789
+PID: 0.779
+
+opensuse 11.2 guest hangs after live migration with clocksource=kvm-clock
+
+i would like to debug a problem that I encountered some time ago with opensuse 11.2 and also
+with Ubuntu (karmic/lucid).
+
+If I run an opensuse guest 64-bit and do not touch the clocksource settings the guest almost
+everytime hangs after live migration at:
+
+(gdb) thread apply all bt
+
+Thread 2 (Thread 0x7f846782a950 (LWP 27356)):
+#0  0x00007f8467d24cd7 in ioctl () from /lib/libc.so.6
+#1  0x000000000042b945 in kvm_run (env=0x2468170)
+  at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921
+#2  0x000000000042cea2 in kvm_cpu_exec (env=0x2468170)
+  at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651
+#3  0x000000000042d62c in kvm_main_loop_cpu (env=0x2468170)
+  at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893
+#4  0x000000000042d76d in ap_main_loop (_env=0x2468170)
+  at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943
+#5  0x00007f8468caa3ba in start_thread () from /lib/libpthread.so.0
+#6  0x00007f8467d2cfcd in clone () from /lib/libc.so.6
+#7  0x0000000000000000 in ?? ()
+
+Thread 1 (Thread 0x7f84692d96f0 (LWP 27353)):
+#0  0x00007f8467d25742 in select () from /lib/libc.so.6
+#1  0x000000000040c25a in main_loop_wait (timeout=1000)
+  at /usr/src/qemu-kvm-0.12.4/vl.c:3994
+#2  0x000000000042dcf1 in kvm_main_loop ()
+  at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126
+#3  0x000000000040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212
+#4  0x000000000041054b in main (argc=31, argv=0x7fffa91351c8,
+  envp=0x7fffa91352c8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252
+
+If I run the same guest with kernel parameter clocksource=acpi_pm, the migration succeeds reliably.
+
+The hosts runs:
+/kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3
+
+I invoke qemu-kvm with:
+/usr/bin/qemu-kvm-0.12.4  -net none  -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native  -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'  -monitor tcp:0:4001,server,nowait -vnc :1 -name 'test'  -boot order=dc,menu=on  -k de  -pidfile /var/run/qemu/vm-149.pid  -mem-path /hugepages -mem-prealloc  -rtc base=utc,clock=vm -usb -usbdevice tablet
+
+The Guest is:
+OpenSuse 11.2 64-bit with Kernel 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 x86_64
+The clocksource automatically choosen is kvm-clock.
+
+Feedback appreciated. I have observed the same problem with 0.12.2 and also with old binaries provided by Ubuntu Karmic (kvm-88).
+
+Update:
+
+Problem still exists with lastest GIT. Ubuntu 9.10 and 10.04 64-bit guests are also affected.
+
+This bug ticket is quite old already ... can you still reproduce this issue with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+