summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/semantic/1366836
blob: 43f52454c999e5987fc810215764a9cd47732714 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
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