qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: bobooscar <bobooscar@gmail.com>
Cc: Amit Shah <amit.shah@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] 回复: Re: 回复: Re: 回复: Re:  Which part of qemu responds to ACPI control method?
Date: Mon, 08 Jul 2013 15:06:24 +0200	[thread overview]
Message-ID: <51DAB950.3090505@redhat.com> (raw)
In-Reply-To: <yhsuki455jnmq934vlt7evaw.1373286261646@email.android.com>

On 07/08/13 14:24, bobooscar wrote:
> To laszlo: unfortunitely, thereˊs no _S3, _S4, _S5 either.
> 
> Back to the *actual* question, the exact problem is as follows:
> 1 We found that the guest os(rhel 6.1) got stuck(suspended) for about
> 30-60 seconds after it migrates from host A to host B.
> 2 such problem doesnˊt occur with guest os rhel6.3
> 3 itˊs stuck on the dest host, which means that, something is wrong with
> “resuming” procedure, rather than the “suspend” procedure.
> 4 we tryed to disable acpi in the guest, (by add “acpi=off” in file
> /boot/grub/menu.lst),  the problem disappeared!!!
> 
> Thus, we suspect that maybe thereˊs some bugs in “acpi” and the “resume”
> procedure in rhel6.1 guest os, or maybe qemu. Is that because acpi got
> to resume a list os devices, and resuming a certain device costs too
> much time?
> 
> There comes a question: how do the guest os and qemu communicate with
> each other, to suspend and resume the guest os, as well as its devices
> with acpi? 
> 
> The exact problem we encouter is: the guest os got suspended for too
> long while itˊs waking up after migration.
> 
> Any suggestion how to analyse and resolve such problem?

Although you didn't specify your host OS / qemu versions, this might be
related to <https://bugzilla.redhat.com/show_bug.cgi?id=886798>. CC'ing
Amit. Considering the first sentence in your email, and assuming that
you use a RHEL-6 host, the by-default lack of _S3 and _S4 implies a
RHEL-6.2+ host.

The problem could be an ACPI bug in the RHEL-6.1 guest kernel too, one
that got fixed for RHEL-6.3. Any reason you're sticking with a 6.1 guest?

The acpi=off guest kernel parameter probably masks the problem in either
case.

You might want to report the problem through your normal RH channels,
with all relevant details. (We're discussing the problem in reverse
direction now.) For example, host version numbers. A guest vmcore while
stuck could be helpful too.

> Meanwhile, to laszlo, what's the purpose of using “
> -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0” to add to
> qemu's args?

qemu-kvm in RHEL-6.4 (= host) disables S3 and S4 by default. The above
options reenable those sleep states.

Laszlo

      reply	other threads:[~2013-07-08 13:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-08 12:24 [Qemu-devel] 回复: Re: 回复: Re: 回复: Re: Which part of qemu responds to ACPI control method? bobooscar
2013-07-08 13:06 ` Laszlo Ersek [this message]

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=51DAB950.3090505@redhat.com \
    --to=lersek@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=bobooscar@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).