1 files changed, 88 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/semantic/1366836 b/results/classifier/zero-shot/105/semantic/1366836
new file mode 100644
index 000000000..43f52454c
--- /dev/null
+++ b/results/classifier/zero-shot/105/semantic/1366836
@@ -0,0 +1,88 @@
+semantic: 0.861
+mistranslation: 0.849
+other: 0.848
+instruction: 0.819
+KVM: 0.818
+boot: 0.817
+device: 0.812
+assembly: 0.801
+graphic: 0.794
+vnc: 0.770
+socket: 0.718
+network: 0.604
+
+Core2Duo and KVM may not boot Win8 properly on 3.x kernels
+
+When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel
+3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error.
+When I dump the CPU registers via "info registers", nothing changes, that means
+the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0.
+
+But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on
+the host side it works on the Core2Duo. Also the system above but just with an
+i3 or i5 CPU it works fine.
+
+I already disabled networking and USB for the guest and changed the graphics
+card - no effect. I assume that some mean bits and bytes have to be set up
+properly to get the thing running.
+
+Seems to be related to a kvm/progressor incompatibility.
+
+Here the register dump of the stalled Win8
+QEMU 2.1.0 monitor - type 'help' for more information
+(qemu) info registers
+EAX=3e2009e3 EBX=3e2009e3 ECX=80000000 EDX=80000000
+ESI=3e2009e3 EDI=8220c108 EBP=81f9b33c ESP=81f9b2f0
+EIP=80c98d83 EFL=00010282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0023 00000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
+CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
+SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+DS =0023 00000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
+FS =0030 80e65000 00004280 00409300 DPL=0 DS   [-WA]
+GS =0000 00000000 ffffffff 00000000
+LDT=0000 00000000 ffffffff 00000000
+TR =0028 80353000 000020ab 00008b00 DPL=0 TSS32-busy
+GDT=     80a37000 000003ff
+IDT=     80a37400 000007ff
+CR0=8001003b CR2=8b206090 CR3=00185000 CR4=000406e9
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000500000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000800
+FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
+FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
+FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
+FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
+FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
+XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
+XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
+XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
+XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
+
+
+I found a new trace - using the ipipe patch that I have, there seems to be an issue in the 3.4 kernels, but as it looks also in the 3.10 kernels.
+http://www.xenomai.org/pipermail/xenomai/2013-March/027865.html
+
+Is there an update on that already existing? It was not completely clear if this issue is related either to KVM or to the ipipe patch.
+
+Thanks.
+
+attached the trace.dat (tar-gzipped) as recommended. Hope this helps finding the issue. The file should capture the following:
+- windows 8 with screen that shows that the last boot attempts failed
+- issued system_reset on qemu commandline
+- startup of windows 8 that stalls
+
+
+sorry for the corrupt file, this one should be fine now.
+
+Confirmed - the current kvm.git without any ipipe patch also causes the issue. Trace File attached.
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+Please close it, it's solved with this patch commit to kvm / kernel:
+Was found and fixed with great support of Paolo Bonzini
+
+From: Paolo Bonzini
+Date: Thu, 12 Feb 2015 17:04:47 +0100
+Subject: KVM: emulate: fix CMPXCHG8B on 32-bit hosts
+
+