All of lore.kernel.org
 help / color / mirror / Atom feed
From: tobias <tobias@appelo.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1174654] Re: qemu-system-x86_64 takes 100% CPU	after host	machine resumed from suspend to ram
Date: Fri, 18 Oct 2013 08:31:13 -0000	[thread overview]
Message-ID: <5260F1D1.7030008@appelo.org> (raw)
In-Reply-To: 20130430080722.32341.54160.malonedeb@gac.canonical.com

Hi,

ok confusion cleared :-)
actually i only have this issue with windows guests. linux guests do not 
show a high cpu usage after suspend resume.
so are there any recommendations you would have to work around it ?

regards,

Tobias.


On 18-10-13 09:42, mike wrote:
> On 10/18/2013 03:41 PM, tobias appelo wrote:
>> Hello MIke,
>>
>> but this concerns a windows guest. you mean a kernel configuration 
>> within the guest (aka recompile ?) or a boot parameter within the 
>> guest ?
>>
> Oh, sorry, I assume it is linux guest :)
>
> for windows, I have no idea of it :)
>
> Thanks
> Mike
>> regards,
>>
>> Tobias.
>>
>> On 18-10-13 09:26, mike wrote:
>>> On 10/18/2013 03:12 PM, tobias wrote:
>>>> Hello Mike,
>>>>
>>>> Thanks a lot for getting back on this.
>>>> Is the "cpu idle driver" a command line option I need to specify for
>>>> qemu (the -cpu option ?)
>>>> I could not find a reference to "idle" in the man page.
>>> You need to check the guest kernel config file.
>>>
>>> Thanks
>>> Mike
>>>> regards,
>>>>
>>>> Tobias.
>>>>
>>>> On 18-10-13 04:33, mike wrote:
>>>>> On 10/18/2013 04:29 AM, tobias wrote:
>>>>>> hi,
>>>>>>
>>>>>> tried your option but it does not help. (cpu usage is still high)
>>>>>> below my command line syntax:
>>>>>> qemu-system-x86_64 -global mc146818rtc.lost_tick_policy=slew 
>>>>>> -machine
>>>>>> accel=kvm:tcg -name win7 -S -machine pc-i440fx-1.4,accel=kvm,usb=off
>>>>>> -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
>>>>>> 813f5806-64ec-3319-452a-5e1834e753c9 -no-user-config -nodefaults
>>>>>> -chardev
>>>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait 
>>>>>>
>>>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
>>>>>> -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7
>>>>>> -device
>>>>>> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 
>>>>>>
>>>>>> -device
>>>>>> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1
>>>>>> -device
>>>>>> ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2
>>>>>> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 
>>>>>> -drive
>>>>>> file=/data/vmware/win7.img,if=none,id=drive-virtio-disk0,format=qcow2 
>>>>>>
>>>>>> -device
>>>>>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 
>>>>>>
>>>>>> -device usb-tablet,id=input0 -device
>>>>>> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
>>>>>> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
>>>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -vga std
>>>>> Hi, have you enable the kernel CPU idle driver? especially the guest
>>>>> kernel.
>>>>>
>>>>> Thanks
>>>>> Mike
>>>>>
>>>
>>
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1174654

Title:
  qemu-system-x86_64 takes 100% CPU after host machine resumed from
  suspend to ram

Status in QEMU:
  Confirmed
Status in “qemu” package in Ubuntu:
  Invalid

Bug description:
  I have Windows XP SP3  inside qemu VM. All works fine in 12.10. But
  after upgraiding to 13.04 i have to restart the VM each time i
  resuming my host machine, because qemu process starts to take CPU
  cycles and OS inside VM is very slow and sluggish. However it's still
  controllable and could be shutdown by itself.

  According to the taskmgr any active process takes 99% CPU. It's not
  stuck on some single process.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1174654/+subscriptions

  parent reply	other threads:[~2013-10-18  8:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-30  8:07 [Qemu-devel] [Bug 1174654] [NEW] qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram Maxim Loparev
2013-04-30 10:04 ` [Qemu-devel] [Bug 1174654] " Maxim Loparev
2013-04-30 12:54 ` [Qemu-devel] [Bug 1174654] [NEW] " Serge Hallyn
2013-04-30 13:32 ` [Qemu-devel] [Bug 1174654] " Maxim Loparev
2013-04-30 13:52   ` Serge Hallyn
2013-04-30 13:42 ` Maxim Loparev
2013-04-30 14:20 ` Maxim Loparev
2013-04-30 14:41 ` Serge Hallyn
2013-04-30 14:50 ` Serge Hallyn
2013-05-08  9:11 ` Maxim Loparev
2013-05-08 15:25   ` Serge Hallyn
2013-05-08 19:01 ` John Basila
2013-07-31 13:34 ` Richard Jones
2013-10-12  9:06 ` tobias
2013-10-13 13:14 ` Paolo Bonzini
2013-10-17 20:29 ` tobias
2013-10-18  2:33   ` mike
2013-10-18  7:12     ` tobias appelo
2013-10-18  7:26       ` mike
2013-10-18  7:41 ` tobias
2013-10-18  8:31 ` tobias [this message]
2013-10-30 21:54 ` tobias
2014-02-04  7:15 ` Matt Keith
2015-07-20  2:59 ` derek
2015-12-18 22:10 ` varacanero
2016-10-06 21:25 ` Jürgen Veidt
2017-01-19 18:17 ` Francois Gouget
2018-12-08 18:43 ` Mark A. Hershberger
2020-11-10 17:57 ` Thomas Huth
2021-01-10  4:17 ` Launchpad Bug Tracker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5260F1D1.7030008@appelo.org \
    --to=tobias@appelo.org \
    --cc=1174654@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.