Bugs item #2235570, was opened at 2008-11-07 18:58 Message generated for change (Comment added) made by jessorensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2235570&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Bailey (dgym) Assigned to: Nobody/Anonymous (nobody) Summary: 100% cpu usage with KVM-78 Initial Comment: When I start a guest it consumes 100% CPU on the host, even after it has booted and is sitting idle at a login prompt. The odd thing is that if I then live migrate the guest to another (identical) machine, the problem goes away. The guest continues to run just fine on the new host, and the new host's CPU usage is normal. I have tried the obvious: starting on the other machine and migrating to the first, and even multiple migrations. It is always the same, the qemu-system-x86_64 process sits at 100% unless it was started with -incoming ... Migrating machines every time you start up is not a very convenient work around, so it would be nice to find out what is different between the normal start up and the -incoming start up and fix the former. Versions and settings: KVM: 78 Host Kernel: Vanilla 2.6.25.2 Compiled with: gcc version 4.1.2 CPU: AMD Phenom Guest OS: Linux (have tried a few distros) Guest Kernels: Debian etch, and an OpenVZ 2.6.18 Command line: qemu-system-x86_64 -m 128 -smp 1 -drive file=/dev/drbd0 -vnc :1 Things I have tried which have not worked: Using -nographics. Using SDL graphics. Using -snapshot, and doing a savevm and loadvm. Things I have tried which have worked: Using -no-kvm. I have attached gdb and found the busy thread, here is its backtrace: #0 0x00007f06f017ea17 in ioctl () from /lib/libc.so.6 #1 0x000000000051b423 in kvm_run (kvm=0xa93040, vcpu=0) at libkvm.c:892 #2 0x00000000004f1116 in kvm_cpu_exec (env=<value optimized out>) at /opt/setup/kvm-78/qemu/qemu-kvm.c:230 #3 0x00000000004f13e4 in ap_main_loop (_env=<value optimized out>) at /opt/setup/kvm-78/qemu/qemu-kvm.c:432 #4 0x00007f06f0565135 in start_thread () from /lib/libpthread.so.0 #5 0x00007f06f01852ce in clone () from /lib/libc.so.6 #6 0x0000000000000000 in ?? () Because this indicates business within the kernel module it is as far as I have got. I will attempt to identify the previous working version, I know I never had this problem with 68, but I haven't yet tried anything in between. ---------------------------------------------------------------------- >Comment By: Jes Sorensen (jessorensen) Date: 2010-11-29 09:00 Message: Hi, Given that there has been no updates to this bug for a long time, I presume the problem has been resolved? Would you mind letting us know if you still see this problem? Thanks, Jes ---------------------------------------------------------------------- Comment By: James Bailey (dgym) Date: 2008-11-08 22:35 Message: Using the -no-kvm-pit option fixes the CPU problem. There were some changes to arch/x86/kvm/i8254.c so this definitely looks PIT related. ---------------------------------------------------------------------- Comment By: James Bailey (dgym) Date: 2008-11-08 21:28 Message: I have been able to narrow the problem down to a single commit. KVM-76 was fine, but I get this broken behaviour with KVM-77. I checked out the KVM userspace and went back to 76, and I also checked out the KVM kernel and tried different versions. Commit 666c4a43cba0cbaa30cd3c86b515dfdab2a6fa98 on git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git is the first version to show the 100% CPU behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2235570&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
