[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

>>> On 28.07.12 at 14:55, Mark van Dijk <lists+xen@xxxxxxxxxxxxxx> wrote:
>> > > So.. in that case make sure you have XEN_ACPI_PROCESSOR=y and
>> > > "CONFIG_INTEL_IDLE is not set" and that should do it.
>> > 
>> > Didn't he say that with INTEL_IDLE disabled things work (perhaps
>> > in a limited way, but at least don't crash)? My understanding is
>> > that things should work even with it enabled, and I was under the
>> > impression that you had already taken care of disabling cpuidle
>> > and cpufreq in the kernel when running on Xen...
>> So did I - both of those (cpufreq and cpuidle) are disabled.
>> Mark, any chance you can collect the serial output when it crashes
>> please? Actually, can you get the whole bootup log with 'loglevel=8
>> debug' on the Linux command line?
> The sad part is that I don't have physical access to the box, the good
> part is that I do have KVM and IPMI (SOL) access.
> This is what I could capture:
> http://i.imgur.com/t66FM.png 

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",
                return retval;

since cpuidle_get_driver() is presumably returning NULL (after
all xen_arch_setup() does call disable_cpuidle()).


Xen-devel mailing list



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