From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwB6z-0003mf-KI for qemu-devel@nongnu.org; Mon, 08 Jul 2013 09:04:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwB6s-0003gx-Te for qemu-devel@nongnu.org; Mon, 08 Jul 2013 09:04:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwB6s-0003fv-LH for qemu-devel@nongnu.org; Mon, 08 Jul 2013 09:04:06 -0400 Message-ID: <51DAB950.3090505@redhat.com> Date: Mon, 08 Jul 2013 15:06:24 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] =?utf-8?b?5Zue5aSN77yaIFJlOiDlm57lpI3vvJogUmU6IA==?= =?utf-8?b?5Zue5aSN77yaIFJlOiAgV2hpY2ggcGFydCBvZiBxZW11IHJlc3BvbmRzIHRv?= =?utf-8?q?_ACPI_control_method=3F?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bobooscar Cc: Amit Shah , qemu-devel@nongnu.org On 07/08/13 14:24, bobooscar wrote: > To laszlo: unfortunitely, there=CB=8As no _S3, _S4, _S5 either. >=20 > 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=CB=8At occur with guest os rhel6.3 > 3 it=CB=8As stuck on the dest host, which means that, something is wron= g with > =E2=80=9Cresuming=E2=80=9D procedure, rather than the =E2=80=9Csuspend=E2= =80=9D procedure. > 4 we tryed to disable acpi in the guest, (by add =E2=80=9Cacpi=3Doff=E2= =80=9D in file > /boot/grub/menu.lst), the problem disappeared!!! >=20 > Thus, we suspect that maybe there=CB=8As some bugs in =E2=80=9Cacpi=E2=80= =9D and the =E2=80=9Cresume=E2=80=9D > 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? >=20 > 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?=20 >=20 > The exact problem we encouter is: the guest os got suspended for too > long while it=CB=8As waking up after migration. >=20 > Any suggestion how to analyse and resolve such problem? Although you didn't specify your host OS / qemu versions, this might be related to . 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=3Doff guest kernel parameter probably masks the problem in eithe= r 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 =E2=80=9C > -global PIIX4_PM.disable_s3=3D0 -global PIIX4_PM.disable_s4=3D0=E2=80=9D= to add to > qemu's args? qemu-kvm in RHEL-6.4 (=3D host) disables S3 and S4 by default. The above options reenable those sleep states. Laszlo