summaryrefslogtreecommitdiffstats
path: root/results/classifier/111/review/1534382
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/111/review/1534382')
-rw-r--r--results/classifier/111/review/153438260
1 files changed, 60 insertions, 0 deletions
diff --git a/results/classifier/111/review/1534382 b/results/classifier/111/review/1534382
new file mode 100644
index 00000000..54f59e8d
--- /dev/null
+++ b/results/classifier/111/review/1534382
@@ -0,0 +1,60 @@
+semantic: 0.170
+other: 0.151
+device: 0.115
+graphic: 0.095
+socket: 0.069
+performance: 0.064
+PID: 0.058
+vnc: 0.045
+boot: 0.044
+permissions: 0.044
+debug: 0.039
+files: 0.038
+KVM: 0.036
+network: 0.032
+debug: 0.710
+KVM: 0.054
+other: 0.037
+socket: 0.034
+PID: 0.031
+files: 0.029
+performance: 0.025
+device: 0.017
+network: 0.015
+graphic: 0.013
+semantic: 0.013
+vnc: 0.009
+boot: 0.008
+permissions: 0.006
+
+loadvm makes Windows 7 x86 guest crash with some CPUs
+
+Running qemu with kvm enabled and -cpu set to some of the more "modern" CPUs,
+and having Windows 7 x86 as the guest.
+
+After guest OS loads, start some app (I started "cmd"), then do "savevm".
+After that, do some more activity (I closed cmd window and opened IE),
+then do "loadvm" of the previously saved snapshot.
+
+loadvm shows briefly the state that the system was in at the snapshot time,
+then guest OS crashes (blue screen).
+
+Originally I saw this problem on qemu 1.4.0,
+then I also tried qemu 2.5.0 and found the same problem.
+
+The CPUs that I tried were mostly those that support NX bit (core2duo,
+qemu64, kvm64, Nehalem, etc.)
+
+If I use the default CPU, or some other like qemu32/kvm32,
+the problem does not occur.
+
+What is your host processor?
+
+it is Intel(R) Xeon(R) CPU E5-1410 0 @ 2.80GHz
+
+
+Looking through 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.]
+