Bugs item #2493108, was opened at 2009-01-08 12:53
Message generated for change (Comment added) made by kmshanah
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493108&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: intel
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Shanahan (kmshanah)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win2k problems on some (not all) Intel hosts
Initial Comment:
I have a Windows 2000 guest that I have been testing on an desktop machine
(E8400 CPU) and that has been working well (apart from being affected by bug
2314737).
When I moved (not a live migration, just shutdown, rsync and boot on the new
server) the guest to our server, which is an IBM X3550 with two Xeon 5130 CPUs
the guest has short "freezes" where the guest CPU usage spikes on both virtual
CPUs and the guest becomes unresponsive for several seconds at a time. These
guest CPU spikes can last over a minute, but the guest might have moments where
it briefly responds to the delayed keystrokes, etc. every few seconds. One
symptom of this behaviour for me last night was that Win2k AD replication was
failing, so it's not just interactive use that suffers.
Something I noticed that may be relevant - due to the other bug (2314737) which
causes each guest CPU to use 100% of the host CPU, whether the guest CPU is
idle or not, I can tell when the guest is having this problem by looking at the
'top' output on the host.
When the guest is operating normally, the host will show the qemu-system-x86_64
process using 200% CPU (the guest is using -smp 2). However, when the guest is
"misbehaving", the host will show the qemu-system-x86_64 process only using
_100%_ CPU. Maybe one of the threads is stuck, or something is forcing them to
share a single core?
Both hosts are running Debian Lenny/Sid, 64-bit with a kernel.org 2.6.28 kernel
and kvm-82.
The command line used in both cases:
/usr/local/kvm/bin/qemu-system-x86_64 \
-smp 2 \
-localtime -m 2048 \
-drive if=ide,file=kvm-ks-02a.img,index=0,media=disk,boot=on \
-drive if=ide,file=kvm-ks-02b.img,index=2,media=disk \
-net nic,vlan=0,macaddr=52:54:00:12:34:68,model=virtio \
-net tap,vlan=0,ifname=tap18,script=no \
-vnc 127.0.0.1:18 -usbdevice tablet \
-daemonize
CPUs on the "good" host:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
cpu MHz : 3000.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx smx
est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 5984.98
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
cpu MHz : 3000.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx smx
est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 5984.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
And the "bad" host:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.117
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant
_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16
xtpr pdcm dca lahf_lm tpr_shadow
bogomips : 3990.23
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.117
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips : 3989.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.117
cache size : 4096 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 2
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips : 3990.01
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
stepping : 6
cpu MHz : 1995.117
cache size : 4096 KB
physical id : 3
siblings : 2
core id : 1
cpu cores : 2
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips : 3990.01
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
----------------------------------------------------------------------
>Comment By: Kevin Shanahan (kmshanah)
Date: 2010-11-30 14:17
Message:
Yes, you can close it. I have moved on to different hardware and no longer
have time to do further testing.
----------------------------------------------------------------------
Comment By: Jes Sorensen (jessorensen)
Date: 2010-11-26 19:07
Message:
Hi,
Going through the bug list and wondering if this is still a problem, or
can we close the bug?
Thanks,
Jes
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493108&group_id=180599
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
