From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KT0XD-0007Jy-CZ for qemu-devel@nongnu.org; Tue, 12 Aug 2008 16:32:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KT0X7-0007JK-4c for qemu-devel@nongnu.org; Tue, 12 Aug 2008 16:32:03 -0400 Received: from [199.232.76.173] (port=47168 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KT0X6-0007JH-VJ for qemu-devel@nongnu.org; Tue, 12 Aug 2008 16:31:57 -0400 Received: from yx-out-1718.google.com ([74.125.44.156]:29701) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KT0X6-0004in-6m for qemu-devel@nongnu.org; Tue, 12 Aug 2008 16:31:56 -0400 Received: by yx-out-1718.google.com with SMTP id 3so1008244yxi.82 for ; Tue, 12 Aug 2008 13:31:52 -0700 (PDT) Message-ID: <48A1F333.7070608@quinthar.com> Date: Tue, 12 Aug 2008 13:31:47 -0700 From: David Barrett MIME-Version: 1.0 Subject: Re: [Qemu-devel] AMD 100% CPU bug; patch available? References: <48A1BBF8.30407@quinthar.com> <200808121219.24859.rickv@hobi.com> In-Reply-To: <200808121219.24859.rickv@hobi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Aha, figured it out. The tip was in dmesg on the guest: > DMI not present or invalid. > ACPI: RSDP signature @ 0xC00FB010 checksum 0 > ACPI: RSDP 000FB010, 0014 (r0 QEMU ) > ACPI: RSDT 07FF0000, 002C (r1 QEMU QEMURSDT 1 QEMU > 1) > ACPI: FACP 07FF002C, 0074 (r1 QEMU QEMUFACP 1 QEMU > 1) > ACPI: DSDT 07FF0100, 0832 (r1 BXPC BXDSDT 1 INTL 20061 > 109) > ACPI: FACS 07FF00C0, 0040 > ACPI: APIC 07FF0938, 0040 (r1 QEMU QEMUAPIC 1 QEMU > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI > ACPI: Disabling ACPI support Adding acpi=force to the kernel boot line fixed it up. (Though strangely, even after adding acpi=force to the kernel boot line, it still dumps this exact same message -- odd. At least the problem went away.) Thanks for the help! -david Rick Vernam wrote: > I'm not so sure there is such a bug - I've been running qemu on AMD 3700 > laptop for years w/o that, or much of any other issue (except once upon a > time an ACPI issue w/ windows guest causing host cpu to peg 100%). > I run gentoo host + various windows/linux guests. > > points of interest may (or may not) be details such as host kernel > configuration? qemu version? qemu options used? built yourself or > pre-packaged? > I don't claim to be able to help you solve the problem, but there's not much > here to work with... > > On Tuesday 12 August 2008 11:36:08 am David Barrett wrote: >> Can anybody confirm that qemu works on an AMD processor with a Linux >> host and Linux guest (ideally Ubuntu 8.04 in both cases) without using >> 100% CPU? (qemu process on the host uses 100% CPU despite all processes >> on the guest being idle.) >> >> Or is there a known bug that qemu with a Ubuntu guest always uses 100% >> CPU on AMD Ubuntu hosts? If so, is there a patch or workaround for it? >> >> I don't know this for certain, but it's the only pattern I can see: I've >> run qemu on a bunch of laptops and servers over the past 12 months -- >> often with the exact same image and exact same commands -- and some >> hosts see the guest VM use limited CPU, and others a solid 100%. This >> seems to be the case whether or not -kernel-kqemu is used. >> >> At first I thought it was an Ubuntu/Fedora Core issue, as I was running >> Ubuntu on laptops and FC4 on servers (and I only saw this problem on >> servers). But I just got a new Ubuntu server and the problem remains. >> >> Now I realize there's another commonality: my servers have been >> AMD-based, whereas laptops were Intel based. With this theory I looked >> through the user forum and saw a strong correlation between reports of >> 100% CPU and AMD processors. >> >> Is this old news or a debunked theory? >> >> Is there some tool like CPUIdle I should be running? Any suggestions >> for how to start debugging the issue? >> >> Thanks! >> >> -david > > > >