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

[Xen-devel] Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume



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 <ke.yu@xxxxxxxxx>
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?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.