qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] 回复: Re: 回复: Re: 回复: Re: Which part of qemu responds t


From: Laszlo Ersek
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130621 Thunderbird/17.0.7

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 via email to

[Prev in Thread] Current Thread [Next in Thread]