Jeremy,
We had verified this patch on our Core i7 platforms, and it should make dom0
hang issue disappear. As Ke described, dom0 shouldn't enter into real C states
in any case, othwerwise it may lead to Xen hypervisor's issues (e.g. timer
issue, scheduler issues and so on.) and result in dom0 hang during boot
eventually. Would you apply this patch to make rebase/master branch work
again? Thanks! :-)
Acked-by : Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
Xiantao
Yu, Ke wrote:
> Fix the issue of domain0 hang when cpuidle is disabled in Xen
>
> when cpuidle is disabled in xen, domain0 will use native cpuidle
> driver to enter real C state, which is not allowed and will cause
> domain0 hang. this patch change the condition check to fix this
> issue.
>
> Signed-off-by: Yu Ke <ke.yu@xxxxxxxxx>
>
> diff --git a/drivers/acpi/processor_idle.c
> b/drivers/acpi/processor_idle.c
> index c2e24ac..a7308bb 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1146,7 +1146,7 @@ int acpi_processor_cst_has_changed(struct
> acpi_processor *pr) if (!pr->flags.power_setup_done)
> return -ENODEV;
>
> - if (processor_cntl_xen_pm()) {
> + if (xen_initial_domain()) {
> acpi_processor_get_power_info(pr);
> processor_cntl_xen_notify(pr,
> PROCESSOR_PM_CHANGE, PM_TYPE_IDLE);
> @@ -1216,7 +1216,7 @@ int __cpuinit acpi_processor_power_init(struct
> acpi_processor *pr,
> * platforms that only support C1.
> */
> if (pr->flags.power) {
> - if (processor_cntl_xen_pm())
> + if (xen_initial_domain())
> processor_cntl_xen_notify(pr,
> PROCESSOR_PM_INIT, PM_TYPE_IDLE);
> else {
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|