From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume Date: Thu, 16 Jun 2011 18:57:39 -0400 Message-ID: <20110616225739.GA8714@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: kevin.tian@intel.com, ke.yu@intel.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I've been eyeing the ACPI S3/S5 code to see what would be necessary to retool, and while testing I found something strange.. I've stuck the code on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v1 I found out that if I don't have this patch: commit 9f301b0a0081676dfc71b7f0898295e6bcba391a Author: Yu Ke Date: Thu Jun 16 17:15:26 2011 -0400 xen/acpi: add xen acpi processor driver (which is in the devel/acpi-s3.v0 branch). the hypervisor, after an S3 resume sits forever in the default_idle. The Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall. http://darnok.org/xen/devel.acpi-s3.v1.serial.log If that patch above is present and I've cpufreq=xen on the Xen hypervisor then Linux kernel gets unstuck and returns to userspace: http://darnok.org/xen/devel.acpi-s3.v0.serial.log (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still gets stuck). I figured that the primary reason the guest is allowed to exit is SCHEDOP_block loop is b/c the pm_idle call is set to the acp_processor_idle which does "something" extra after the machine comes out of a S3 suspend. Any ideas?