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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jul 26, 2012 at 02:25:27AM +0200, Mark van Dijk wrote:
> Hi Konrad,
> 
> > > When I set CONFIG_ACPI_PROCESSOR, CONFIG_CPU_IDLE and
> > > CONFIG_INTEL_IDLE to y then I cannot boot Xen; there is a crash. If
> > > I turn CONFIG_INTEL_IDLE off then the boot goes well and, after
> > > dom0 has booted, xenpm works and gives some sane output, see below.
> > > I have tested this with kernels 3.2 to 3.4.6. 
> > > 
> > > Is it impossible to use INTEL_IDLE with Xen? If this is a known
> > > issue then maybe someone can add info to the INTEL_IDLE help text
> > > in the kernel configuration...
> > 
> > Could be - without a serial crash it is hard to figure out.
> 
> Alright, I will enable INTEL_IDLE again so that I can report the crash
> message. Won't be now but it will be within the next few days.
> 
> > Why do you want to use the intel idle driver? Can't you use
> > the xen-acpi-processor driver which does the job of uploading
> > the power management data to the hypervisor.
> > 
> > (CONFIG_XEN_ACPI_PROCESSOR is the option you need to have enabled).
> 
> I just checked - I have enabled this option. It is in Device Drivers ->
> Xen driver support which did confuse me somewhat, partially because the
> rest of the ACPI options are under 'Power management and ACPI
> options', also because the options look alike so much, I suppose
> fatigue kicked in. :)
> 
> Anyway, It seems that CONFIG_XEN_ACPI_PROCESSOR depends on
> ACPI_PROCESSOR, see below.
> 
> To answer your question about why I want to use the intel idle driver.
> Actually I don't want/need to use it per se.. I simply thought it was
> the logical choice to enable it in order to be able to use Intel
> specific idle instructions.
> 
> > > I am using this on a dual CPU motherboard, it has two Xeon W3530
> > > CPUs (i.e. family 6, model 26, stepping 5). I have also tested this
> > > with a single-CPU Core2 Quad Q6600 and the same situation occurs
> > > here, but the below output is of the W3530 Xeon system.
> > > 
> > > While I'm not that familiar with CPUidle, one thing that seems to be
> > > not right is that the maximum idle state here is C3 while the
> > > processor should be able to reach as far as C7.
> > 
> > Right, it won't unless you don't compile acpi_pad
> > (CONFIG_ACPI_PROCESSOR). Is # CONFIG_ACPI_PROCESSOR  is not set"  in
> > your .config?
> 
> No, and this is where I start to wonder. I have built in the CPUFREQ
> drivers and the kernel help text says that when this is the case,
> CONFIG_XEN_ACPI_PROCESSOR must be Y as well. For this to work I have to
> set CONFIG_ACPI_PROCESSOR to Y because:
> 
> XEN_ACPI_PROCESSOR [=y]
> Depends on: XEN [=y] && X86 [=y] && ACPI_PROCESSOR [=y] && CPU_FREQ [=y]
> 
> The full .config is here:
> http://pastebin.com/36a2tVYj
> 
> What I am after: cpu scheduling (xenpm set-cpufreq-governor) and
> maximum idle states. But you can see that I am not as knowledgable as
> yourself, so further hints or requests for debugging are welcome (the
> INTEL_IDLE boot crash message will be posted when I am able to fiddle
> with the kernel again) and thanks so far for your answers.

So.. in that case make sure you have XEN_ACPI_PROCESSOR=y and
"CONFIG_INTEL_IDLE is not set" and that should do it.

I got the ACPI_PAD and ACPI_PROCESSOR confused. The option I wanted
you to unset is: CONFIG_ACPI_PROCESSOR_AGGREGATOR, sorry about that.
If you unset that ("# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set") that
should allow MWAIT and lower states to be reached by the hypervisor.

You can verify that by booting Xen with 'cpufreq=verbose' and during
the bootup should see in the 'xl dmesg' something like this:

(XEN) Set CPU acpi_id(0) cpuid(0) Px State info:^M
(XEN)   _PCT: descriptor=130, length=12, space_id=127, bit_width=64, 
bit_offset=0, reserved=0, address=3221291106^M
(XEN)   _PCT: descriptor=130, length=12, space_id=127, bit_width=64, 
bit_offset=0, reserved=0, address=0^M
(XEN)   _PSS: state_count=4^M
(XEN)   State0: 2900MHz 32062mW 8us 8us 0x0 0x0^M
(XEN)   State1: 2200MHz 27030mW 8us 8us 0x1 0x1^M
(XEN)   State2: 1700MHz 23152mW 8us 8us 0x2 0x2^M
(XEN)   State3: 800MHz 8325mW 8us 8us 0x3 0x3^M
(XEN)   _PSD: num_entries=5 rev=0 domain=0 coord_type=253 num_processors=1^M
(XEN)   _PPC: 0^M
(XEN) max_freq: 2900000    second_max_freq: 2200000^M
(XEN) CPU 0 initialization completed^M
(XEN) Set CPU acpi_id(1) cpuid(1) Px State info:^M
(XEN)   _PCT: descriptor=130, length=12, space_id=127, bit_width=64, 
bit_offset=0, reserved=0, address=3221291106^M
(XEN)   _PCT: descriptor=130, length=12, space_id=127, bit_width=64, 
bit_offset=0, reserved=0, address=0^M
(XEN)   _PSS: state_count=4^M
(XEN)   State0: 2900MHz 32062mW 8us 8us 0x0 0x0^M
(XEN)   State1: 2200MHz 27030mW 8us 8us 0x1 0x1^M
(XEN)   State2: 1700MHz 23152mW 8us 8us 0x2 0x2^M
(XEN)   State3: 800MHz 8325mW 8us 8us 0x3 0x3^M

or running xenpm get-cpufreq to check out the details.
> 
> Mark
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel