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

Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y

Message 501657C70200007800091357@xxxxxxxxxxxxxxxxxxxx contained:
>The first thing intel_idle_init() does is check
>boot_option_idle_override, and I thought this got forced to
>something other than IDLE_NO_OVERRIDE by the Xen code.
>But at least in the current kernel that doesn't seem to be
>the case anymore, and thus I suppose that it's dying on the
>       retval = cpuidle_register_driver(&intel_idle_driver);
>       if (retval) {
>               printk(KERN_DEBUG PREFIX "intel_idle yielding to %s",
>                       cpuidle_get_driver()->name);
>               return retval;
>       }
>since cpuidle_get_driver() is presumably returning NULL (after
>all xen_arch_setup() does call disable_cpuidle()).

This is way beyond my knowledge. I'm no programmer so unfortunately I
can't say anything about it.

Not using INTEL_IDLE is no problem, in fact, I now understand that
INTEL_IDLE is not (should not) even used with Xen.

But I have to ask whether we can look at the other issue a bit more,
regarding CPU states and how I can get states C4-C7 to work.

Perhaps you can tell me whether the BIOS options "ACPI T-state",
"C3 Auto Demotion" and "C1 Auto Demotion" should be disabled. I think
they should be, as I read it this sets respectively C4-C7 to C3, and
C3-C2 to C1 right? I have (and had) those disabled, when I enabled them
the output from xenpm did not differ.

Much obliged,


Stay in touch,
Mark van Dijk.              ,--------------------------------
---------------------------'        Tue Jul 31 11:28 UTC 2012
Today is Boomtime, the 66th day of Confusion in the YOLD 3178

Xen-devel mailing list



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