Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

Hello,

Does anyone know why loading xen-acpi-processor driver fails like this?:

# modprobe xen-acpi-processor
FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error

Using "modprobe -v" doesn't provide any more information about the problem.
Also there's nothing in dom0 kernel dmesg.

Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
Xen 4.2.1.

Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
with some additional Xen patches backported from later upstream kernels. 
Any tips how to troubleshoot this? 

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> Hello,
> 
> Does anyone know why loading xen-acpi-processor driver fails like this?:
> 
> # modprobe xen-acpi-processor
> FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> 
> Using "modprobe -v" doesn't provide any more information about the problem.
> Also there's nothing in dom0 kernel dmesg.
> 
> Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> Xen 4.2.1.
> 
> Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> with some additional Xen patches backported from later upstream kernels. 
> Any tips how to troubleshoot this? 

Rebuild the module and add this
diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
index 316df65..5d824a2 100644
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -16,6 +16,7 @@
  * more details.
  *
  */
+#define DEBUG 1
 
 #include <linux/cpumask.h>
 #include <linux/cpufreq.h>


That should help in figuring it out.

> 
> -- Pasi
> 

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > 
> > # modprobe xen-acpi-processor
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > 
> > Using "modprobe -v" doesn't provide any more information about the problem.
> > Also there's nothing in dom0 kernel dmesg.
> > 
> > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> > Xen 4.2.1.
> > 
> > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> > with some additional Xen patches backported from later upstream kernels. 
> > Any tips how to troubleshoot this? 
> 
> Rebuild the module and add this
> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> index 316df65..5d824a2 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -16,6 +16,7 @@
>   * more details.
>   *
>   */
> +#define DEBUG 1
>  
>  #include <linux/cpumask.h>
>  #include <linux/cpufreq.h>
> 
> 
> That should help in figuring it out.
> 

Ok, I'll do that.

Thanks!

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > 
> > # modprobe xen-acpi-processor
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > 
> > Using "modprobe -v" doesn't provide any more information about the problem.
> > Also there's nothing in dom0 kernel dmesg.
> > 
> > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> > Xen 4.2.1.
> > 
> > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> > with some additional Xen patches backported from later upstream kernels. 
> > Any tips how to troubleshoot this? 
> 
> Rebuild the module and add this
> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> index 316df65..5d824a2 100644
> --- a/drivers/xen/xen-acpi-processor.c
> +++ b/drivers/xen/xen-acpi-processor.c
> @@ -16,6 +16,7 @@
>   * more details.
>   *
>   */
> +#define DEBUG 1
>  
>  #include <linux/cpumask.h>
>  #include <linux/cpufreq.h>
> 
> 
> That should help in figuring it out.
> 

This is what I get with DEBUG enabled:

# modprobe -v xen-acpi-processor
insmod /lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-processor.ko
FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error

in dom0 kernel dmesg:
xen-acpi-processor: Max ACPI ID: 24

.. and that's all.

Adding more debug options on the kernel cmdline I see this:
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned -5 after 67 usecs
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5

And enabling some ACPI debug options:
processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable


I added a bunch of more calls to pr_debug() in xen_acpi_processor_init() and it seems:

        /* Do initialization in ACPI core. It is OK to fail here. */
        (void)acpi_processor_preregister_performance(acpi_perf_data);

        for_each_possible_cpu(i) {
                struct acpi_processor_performance *perf;

                perf = per_cpu_ptr(acpi_perf_data, i);
                rc = acpi_processor_register_performance(perf, i);
                if (rc)
                        goto err_out;
        }

"goto err_out" is the path taken from here..
It seems acpi_processor_register_performance() returns -EIO.

.. which means in acpi_processor_register_performance()

        if (acpi_processor_get_performance_info(pr)) {
                pr->performance = NULL;
                mutex_unlock(&performance_mutex);
                return -EIO;
        }


It seems acpi_processor_get_performance_info() returns -ENODEV:

        if (ACPI_FAILURE(status)) {
                ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                                  "ACPI-based processor performance control unavailable\n"));
                return -ENODEV;
        }


Does this ring any bells? 

Thanks,

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Thu, Feb 21, 2013 at 02:42:52PM +0200, Pasi Kärkkäinen wrote:
> On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> > > Hello,
> > > 
> > > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > > 
> > > # modprobe xen-acpi-processor
> > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > > 
> > > Using "modprobe -v" doesn't provide any more information about the problem.
> > > Also there's nothing in dom0 kernel dmesg.
> > > 
> > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> > > Xen 4.2.1.
> > > 
> > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> > > with some additional Xen patches backported from later upstream kernels. 
> > > Any tips how to troubleshoot this? 
> > 
> > Rebuild the module and add this
> > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> > index 316df65..5d824a2 100644
> > --- a/drivers/xen/xen-acpi-processor.c
> > +++ b/drivers/xen/xen-acpi-processor.c
> > @@ -16,6 +16,7 @@
> >   * more details.
> >   *
> >   */
> > +#define DEBUG 1
> >  
> >  #include <linux/cpumask.h>
> >  #include <linux/cpufreq.h>
> > 
> > 
> > That should help in figuring it out.
> > 
> 
> Ok, I'll do that.
> 
> Thanks!

The other thing is that I've been running with this compiled as '=y' instead
of '=m'!

That should temporarily fix it for you, but this does need to be fixed.

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Mon, Feb 25, 2013 at 12:03:21PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 21, 2013 at 02:42:52PM +0200, Pasi Kärkkäinen wrote:
> > On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> > > > Hello,
> > > > 
> > > > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > > > 
> > > > # modprobe xen-acpi-processor
> > > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > > > 
> > > > Using "modprobe -v" doesn't provide any more information about the problem.
> > > > Also there's nothing in dom0 kernel dmesg.
> > > > 
> > > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> > > > Xen 4.2.1.
> > > > 
> > > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> > > > with some additional Xen patches backported from later upstream kernels. 
> > > > Any tips how to troubleshoot this? 
> > > 
> > > Rebuild the module and add this
> > > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> > > index 316df65..5d824a2 100644
> > > --- a/drivers/xen/xen-acpi-processor.c
> > > +++ b/drivers/xen/xen-acpi-processor.c
> > > @@ -16,6 +16,7 @@
> > >   * more details.
> > >   *
> > >   */
> > > +#define DEBUG 1
> > >  
> > >  #include <linux/cpumask.h>
> > >  #include <linux/cpufreq.h>
> > > 
> > > 
> > > That should help in figuring it out.
> > > 
> > 
> > Ok, I'll do that.
> > 
> > Thanks!
> 
> The other thing is that I've been running with this compiled as '=y' instead
> of '=m'!
> 
> That should temporarily fix it for you, but this does need to be fixed.
>

Actually it seems I'm getting the exact same problem even with CONFIG_XEN_ACPI_PROCESSOR=y.

I guess I'll have to dig deeper into the ACPI code..

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Mon, Feb 25, 2013 at 12:05:24AM +0200, Pasi Kärkkäinen wrote:
> On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> > > Hello,
> > > 
> > > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > > 
> > > # modprobe xen-acpi-processor
> > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > > 
> > > Using "modprobe -v" doesn't provide any more information about the problem.
> > > Also there's nothing in dom0 kernel dmesg.
> > > 
> > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> > > Xen 4.2.1.
> > > 
> > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> > > with some additional Xen patches backported from later upstream kernels. 
> > > Any tips how to troubleshoot this? 
> > 
> > Rebuild the module and add this
> > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> > index 316df65..5d824a2 100644
> > --- a/drivers/xen/xen-acpi-processor.c
> > +++ b/drivers/xen/xen-acpi-processor.c
> > @@ -16,6 +16,7 @@
> >   * more details.
> >   *
> >   */
> > +#define DEBUG 1
> >  
> >  #include <linux/cpumask.h>
> >  #include <linux/cpufreq.h>
> > 
> > 
> > That should help in figuring it out.
> > 
> 
> This is what I get with DEBUG enabled:
> 
> # modprobe -v xen-acpi-processor
> insmod /lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-processor.ko
> FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> 
> in dom0 kernel dmesg:
> xen-acpi-processor: Max ACPI ID: 24
> 
> .. and that's all.
> 
> Adding more debug options on the kernel cmdline I see this:
> initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned -5 after 67 usecs
> initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> 
> And enabling some ACPI debug options:
> processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable
> 
> 
> I added a bunch of more calls to pr_debug() in xen_acpi_processor_init() and it seems:
> 
>         /* Do initialization in ACPI core. It is OK to fail here. */
>         (void)acpi_processor_preregister_performance(acpi_perf_data);
> 
>         for_each_possible_cpu(i) {
>                 struct acpi_processor_performance *perf;
> 
>                 perf = per_cpu_ptr(acpi_perf_data, i);
>                 rc = acpi_processor_register_performance(perf, i);
>                 if (rc)
>                         goto err_out;
>         }
> 
> "goto err_out" is the path taken from here..
> It seems acpi_processor_register_performance() returns -EIO.
> 
> .. which means in acpi_processor_register_performance()
> 
>         if (acpi_processor_get_performance_info(pr)) {
>                 pr->performance = NULL;
>                 mutex_unlock(&performance_mutex);
>                 return -EIO;
>         }
> 
> 
> It seems acpi_processor_get_performance_info() returns -ENODEV:
> 
>         if (ACPI_FAILURE(status)) {
>                 ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>                                   "ACPI-based processor performance control unavailable\n"));
>                 return -ENODEV;
>         }
> 
> 
> Does this ring any bells? 
> 

so in acpi_processor_get_performance_info():

status = acpi_get_handle(pr->handle, "_PCT", &handle);
if (ACPI_FAILURE(status)) {
	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
			  "ACPI-based processor performance control unavailable\n"));
	return -ENODEV;
}

This is the issue I'm hitting. 
acpi_get_handle() returns an error so -ENODEV is returned from acpi_processor_get_performance_info().

Debugging acpi_get_handle() reveals the pathname[] ("_PCT") passed isn't valid for some reason,
so acpi_ns_valid_root_prefix(pathname[0]) returns false, and a bunch of code is skipped in acpi_get_handle().

Later in acpi_get_handle(): status = acpi_ns_get_node() shows this in dmesg:

 nsutils-0363 [82933056] [00] ns_build_internal_name: Returning [ffff8800040f6240] (rel) "_PCT"
 utmutex-0261 [82933056] [00] ut_acquire_mutex      : Thread 82933056 attempting to acquire Mutex [ACPI_MTX_Namespace]
     osl-1058 [82933056] [00] os_wait_semaphore     : Waiting for semaphore[ffff880039c01aa0|1|65535]
     osl-1077 [82933056] [00] os_wait_semaphore     : Acquired semaphore[ffff880039c01aa0|1|65535] utmutex-0269 [82933056] [00] ut_acquire_mutex      : Thread 82933056 acquired Mutex [ACPI_MTX_Namespace]
nsaccess-0398 [82933056] [00] ns_lookup             : Searching relative to prefix scope [CPU1] (ffff880039699240)
nsaccess-0510 [82933056] [00] ns_lookup             : Simple Pathname (1 segment, Flags=2)
  nsdump-0087 [82933056] [00] ns_print_pathname     : [_PCT]
nssearch-0114 [82933056] [00] ns_search_one_scope   : Searching \_PR_.CPU1 (ffff880039699240) For [_PCT] (Untyped)
nssearch-0168 [82933056] [00] ns_search_one_scope   : Name [_PCT] (Untyped) not found in search in scope [CPU1] ffff880039699240 first child ffff8800396a4e48
nssearch-0379 [82933056] [00] ns_search_and_enter   : _PCT Not found in ffff880039699240 [Not adding]
nsaccess-0571 [82933056] [00] ns_lookup             : Name [_PCT] not found in scope [CPU1] ffff880039699240
 nsutils-0743 [82933056] [00] ns_get_node           : _PCT, AE_NOT_FOUND
 utmutex-0300 [82933056] [00] ut_release_mutex      : Thread 82933056 releasing Mutex [ACPI_MTX_Namespace]
     osl-1097 [82933056] [00] os_signal_semaphore   : Signaling semaphore[ffff880039c01aa0|1]


.. and thus ACPI_SUCCESS(status) is false. _PCT was not found.
Any ideas why the Performance Control stuff can't be found? 

Thanks,

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Sun, Mar 03, 2013 at 08:53:47PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Feb 25, 2013 at 12:05:24AM +0200, Pasi Kärkkäinen wrote:
> > On Thu, Feb 21, 2013 at 07:29:13AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 21, 2013 at 11:24:34AM +0200, Pasi Kärkkäinen wrote:
> > > > Hello,
> > > > 
> > > > Does anyone know why loading xen-acpi-processor driver fails like this?:
> > > > 
> > > > # modprobe xen-acpi-processor
> > > > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.el6.centos.alt.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > > > 
> > > > Using "modprobe -v" doesn't provide any more information about the problem.
> > > > Also there's nothing in dom0 kernel dmesg.
> > > > 
> > > > Hardware is Dell R510 server with Intel Xeon 5600 series CPU. 
> > > > Xen 4.2.1.
> > > > 
> > > > Kernel is based on 3.4.32 (so the upstream kernel.org longterm stable version) 
> > > > with some additional Xen patches backported from later upstream kernels. 
> > > > Any tips how to troubleshoot this? 
> > > 
> > > Rebuild the module and add this
> > > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> > > index 316df65..5d824a2 100644
> > > --- a/drivers/xen/xen-acpi-processor.c
> > > +++ b/drivers/xen/xen-acpi-processor.c
> > > @@ -16,6 +16,7 @@
> > >   * more details.
> > >   *
> > >   */
> > > +#define DEBUG 1
> > >  
> > >  #include <linux/cpumask.h>
> > >  #include <linux/cpufreq.h>
> > > 
> > > 
> > > That should help in figuring it out.
> > > 
> > 
> > This is what I get with DEBUG enabled:
> > 
> > # modprobe -v xen-acpi-processor
> > insmod /lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-processor.ko
> > FATAL: Error inserting xen_acpi_processor (/lib/modules/3.4.32-6.dbg1.el6.x86_64/kernel/drivers/xen/xen-acpi-processor.ko): Input/output error
> > 
> > in dom0 kernel dmesg:
> > xen-acpi-processor: Max ACPI ID: 24
> > 
> > .. and that's all.
> > 
> > Adding more debug options on the kernel cmdline I see this:
> > initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned -5 after 67 usecs
> > initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> > 
> > And enabling some ACPI debug options:
> > processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable
> > 
> > 
> > I added a bunch of more calls to pr_debug() in xen_acpi_processor_init() and it seems:
> > 
> >         /* Do initialization in ACPI core. It is OK to fail here. */
> >         (void)acpi_processor_preregister_performance(acpi_perf_data);
> > 
> >         for_each_possible_cpu(i) {
> >                 struct acpi_processor_performance *perf;
> > 
> >                 perf = per_cpu_ptr(acpi_perf_data, i);
> >                 rc = acpi_processor_register_performance(perf, i);
> >                 if (rc)
> >                         goto err_out;
> >         }
> > 
> > "goto err_out" is the path taken from here..
> > It seems acpi_processor_register_performance() returns -EIO.
> > 
> > .. which means in acpi_processor_register_performance()
> > 
> >         if (acpi_processor_get_performance_info(pr)) {
> >                 pr->performance = NULL;
> >                 mutex_unlock(&performance_mutex);
> >                 return -EIO;
> >         }
> > 
> > 
> > It seems acpi_processor_get_performance_info() returns -ENODEV:
> > 
> >         if (ACPI_FAILURE(status)) {
> >                 ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> >                                   "ACPI-based processor performance control unavailable\n"));
> >                 return -ENODEV;
> >         }
> > 
> > 
> > Does this ring any bells? 
> > 
> 
> so in acpi_processor_get_performance_info():
> 
> status = acpi_get_handle(pr->handle, "_PCT", &handle);
> if (ACPI_FAILURE(status)) {
> 	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> 			  "ACPI-based processor performance control unavailable\n"));
> 	return -ENODEV;
> }
> 
> This is the issue I'm hitting. 
> acpi_get_handle() returns an error so -ENODEV is returned from acpi_processor_get_performance_info().
> 
> Debugging acpi_get_handle() reveals the pathname[] ("_PCT") passed isn't valid for some reason,
> so acpi_ns_valid_root_prefix(pathname[0]) returns false, and a bunch of code is skipped in acpi_get_handle().
> 
> Later in acpi_get_handle(): status = acpi_ns_get_node() shows this in dmesg:
> 
>  nsutils-0363 [82933056] [00] ns_build_internal_name: Returning [ffff8800040f6240] (rel) "_PCT"
>  utmutex-0261 [82933056] [00] ut_acquire_mutex      : Thread 82933056 attempting to acquire Mutex [ACPI_MTX_Namespace]
>      osl-1058 [82933056] [00] os_wait_semaphore     : Waiting for semaphore[ffff880039c01aa0|1|65535]
>      osl-1077 [82933056] [00] os_wait_semaphore     : Acquired semaphore[ffff880039c01aa0|1|65535] utmutex-0269 [82933056] [00] ut_acquire_mutex      : Thread 82933056 acquired Mutex [ACPI_MTX_Namespace]
> nsaccess-0398 [82933056] [00] ns_lookup             : Searching relative to prefix scope [CPU1] (ffff880039699240)
> nsaccess-0510 [82933056] [00] ns_lookup             : Simple Pathname (1 segment, Flags=2)
>   nsdump-0087 [82933056] [00] ns_print_pathname     : [_PCT]
> nssearch-0114 [82933056] [00] ns_search_one_scope   : Searching \_PR_.CPU1 (ffff880039699240) For [_PCT] (Untyped)
> nssearch-0168 [82933056] [00] ns_search_one_scope   : Name [_PCT] (Untyped) not found in search in scope [CPU1] ffff880039699240 first child ffff8800396a4e48
> nssearch-0379 [82933056] [00] ns_search_and_enter   : _PCT Not found in ffff880039699240 [Not adding]
> nsaccess-0571 [82933056] [00] ns_lookup             : Name [_PCT] not found in scope [CPU1] ffff880039699240
>  nsutils-0743 [82933056] [00] ns_get_node           : _PCT, AE_NOT_FOUND
>  utmutex-0300 [82933056] [00] ut_release_mutex      : Thread 82933056 releasing Mutex [ACPI_MTX_Namespace]
>      osl-1097 [82933056] [00] os_signal_semaphore   : Signaling semaphore[ffff880039c01aa0|1]
> 
> 
> .. and thus ACPI_SUCCESS(status) is false. _PCT was not found.
> Any ideas why the Performance Control stuff can't be found? 


No, but I usually do one more thing to check my assumptions. I extract
the SSDT and DSDT:

cat /sys/firmware/acpi/DSDT > /tmp/dsdt

iasl -d /tmp/dsdt
and search for the _PCT to make sure they are actually there.


Independetly of this I was looking at seeing why on v3.9-rc1 it would not work, and
found out that this patch:

d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date:   Thu Jan 17 16:22:21 2013 +0000

    cpufreq: handle cpufreq being disabled for all exported function.

makes acpi_processor_register_performance return -22. Which is b/c


824         if (!(acpi_processor_ppc_status & PPC_REGISTERED)) {

and that is b/c:

227 void acpi_processor_ppc_init(void)
228 {
229         if (!cpufreq_register_notifier
230             (&acpi_ppc_notifier_block, CPUFREQ_POLICY_NOTIFIER))
231                 acpi_processor_ppc_status |= PPC_REGISTERED;
232         else
233                 printk(KERN_DEBUG
234                        "Warning: Processor Platform Limit not supported.\n");
235 }

'cpufreq_register_notifier' fails and acpi_processor_ppc_status is not set
to PPC_REGISTERED. 


> 
> Thanks,
> 
> -- Pasi
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Tue, Mar 05, 2013 at 12:45:15PM -0500, Konrad Rzeszutek Wilk wrote:
> > 
> > .. and thus ACPI_SUCCESS(status) is false. _PCT was not found.
> > Any ideas why the Performance Control stuff can't be found? 
> 
> 
> No, but I usually do one more thing to check my assumptions. I extract
> the SSDT and DSDT:
> 
> cat /sys/firmware/acpi/DSDT > /tmp/dsdt
>

In dom0:

cat: /sys/firmware/acpi/DSDT: No such file or directory

# ls /sys/firmware/acpi/
interrupts  pm_profile  tables

 
> iasl -d /tmp/dsdt
> and search for the _PCT to make sure they are actually there.
>

I don't seem to have /sys/firmware/acpi/DSDT on baremetal either.. 
I wonder what's going on.. 

'acpidump' from pmtools seems to be able to dump the DSDT.
(on baremetal):

# acpidump --table DSDT -b -o dsdt.bin
# iasl -d dsdt.bin 

Intel ACPI Component Architecture
AML Disassembler version 20090123 [Oct 23 2012]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file dsdt.bin
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
..............................................................................................................................................................................................................................................................................................................................................................
Parsing completed
Disassembly completed, written to "dsdt.dsl"


# grep -i pct dsdt.dsl | wc -l
0


# acpidump --table SSDT -b -o ssdt.bin
# iasl -d ssdt.bin 

Intel ACPI Component Architecture
AML Disassembler version 20090123 [Oct 23 2012]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file ssdt.bin
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
................................................................................................................................................................................................................................................................................................................................................................................................................................................
Parsing completed
Disassembly completed, written to "ssdt.dsl"


# grep -i pct ssdt.dsl | wc -l
0


So uhm.. is this a BIOS/firmware bug? 


-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Wed, Mar 06, 2013 at 10:41:39PM +0200, Pasi Kärkkäinen wrote:
> On Tue, Mar 05, 2013 at 12:45:15PM -0500, Konrad Rzeszutek Wilk wrote:
> > > 
> > > .. and thus ACPI_SUCCESS(status) is false. _PCT was not found.
> > > Any ideas why the Performance Control stuff can't be found? 
> > 
> > 
> > No, but I usually do one more thing to check my assumptions. I extract
> > the SSDT and DSDT:
> > 
> > cat /sys/firmware/acpi/DSDT > /tmp/dsdt
> >
> 
> In dom0:
> 
> cat: /sys/firmware/acpi/DSDT: No such file or directory
> 
> # ls /sys/firmware/acpi/
> interrupts  pm_profile  tables
>

Actually the correct path is: /sys/firmware/acpi/tables/DSDT
So the acpi tables are there.

.. but the problem is there's no _PCT info in them.


-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Wed, Mar 06, 2013 at 11:01:27PM +0200, Pasi Kärkkäinen wrote:
> On Wed, Mar 06, 2013 at 10:41:39PM +0200, Pasi Kärkkäinen wrote:
> > On Tue, Mar 05, 2013 at 12:45:15PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > 
> > > > .. and thus ACPI_SUCCESS(status) is false. _PCT was not found.
> > > > Any ideas why the Performance Control stuff can't be found? 
> > > 
> > > 
> > > No, but I usually do one more thing to check my assumptions. I extract
> > > the SSDT and DSDT:
> > > 
> > > cat /sys/firmware/acpi/DSDT > /tmp/dsdt
> > >
> > 
> > In dom0:
> > 
> > cat: /sys/firmware/acpi/DSDT: No such file or directory
> > 
> > # ls /sys/firmware/acpi/
> > interrupts  pm_profile  tables
> >
> 
> Actually the correct path is: /sys/firmware/acpi/tables/DSDT
> So the acpi tables are there.
> 
> .. but the problem is there's no _PCT info in them.
> 

.. so on which hardware is xen-acpi-processor driver required? 

Is the actual problem that I don't have _PCT because it's not required/supported on my hw,
and thus I don't need the whole xen-acpi-processor driver? 

I checked the Xeon 5600 CPU, and also Ivy Bridge i7, and there's no _PCT on either one..

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Wed, Mar 06, 2013 at 11:21:47PM +0200, Pasi Kärkkäinen wrote:
> On Wed, Mar 06, 2013 at 11:01:27PM +0200, Pasi Kärkkäinen wrote:
> > On Wed, Mar 06, 2013 at 10:41:39PM +0200, Pasi Kärkkäinen wrote:
> > > On Tue, Mar 05, 2013 at 12:45:15PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > 
> > > > > .. and thus ACPI_SUCCESS(status) is false. _PCT was not found.
> > > > > Any ideas why the Performance Control stuff can't be found? 
> > > > 
> > > > 
> > > > No, but I usually do one more thing to check my assumptions. I extract
> > > > the SSDT and DSDT:
> > > > 
> > > > cat /sys/firmware/acpi/DSDT > /tmp/dsdt
> > > >
> > > 
> > > In dom0:
> > > 
> > > cat: /sys/firmware/acpi/DSDT: No such file or directory
> > > 
> > > # ls /sys/firmware/acpi/
> > > interrupts  pm_profile  tables
> > >
> > 
> > Actually the correct path is: /sys/firmware/acpi/tables/DSDT
> > So the acpi tables are there.
> > 
> > .. but the problem is there's no _PCT info in them.
> > 
> 
> .. so on which hardware is xen-acpi-processor driver required? 
> 
> Is the actual problem that I don't have _PCT because it's not required/supported on my hw,
> and thus I don't need the whole xen-acpi-processor driver? 
> 
> I checked the Xeon 5600 CPU, and also Ivy Bridge i7, and there's no _PCT on either one..

I always forget which of _P* are important. I think _PPC, _PSS and _PCD
are the crucial ones. The _PCT is the thermal one - which I think are usually
found on laptops.

In your case then .. lets go back to the start - the driver failed with -EIO
and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
I can take a look at this.

> 
> -- Pasi
> 

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Wed, Mar 06, 2013 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> > > 
> > > Actually the correct path is: /sys/firmware/acpi/tables/DSDT
> > > So the acpi tables are there.
> > > 
> > > .. but the problem is there's no _PCT info in them.
> > > 
> > 
> > .. so on which hardware is xen-acpi-processor driver required? 
> > 
> > Is the actual problem that I don't have _PCT because it's not required/supported on my hw,
> > and thus I don't need the whole xen-acpi-processor driver? 
> > 
> > I checked the Xeon 5600 CPU, and also Ivy Bridge i7, and there's no _PCT on either one..
> 
> I always forget which of _P* are important. I think _PPC, _PSS and _PCD
> are the crucial ones. The _PCT is the thermal one - which I think are usually
> found on laptops.
> 

I don't seem to have _PCT on my Ivy Bridge i7 laptop.. 

> In your case then .. lets go back to the start - the driver failed with -EIO
> and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
> I can take a look at this.
> 

Ok.

So the problem for me with Linux 3.4.32 kernel is "modprobe xen-acpi-processor" fails:
initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5

The error deeper down in the ACPI internals is:
processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable

Function call path is this:

xen_acpi_processor_init()
	acpi_processor_register_performance(perf, i) 			<-- returns -EIO
		acpi_processor_get_performance_info(pr)			<-- returns -ENODEV and prints the error to dmesg
			acpi_get_handle(pr->handle, "_PCT", &handle);	
				acpi_ns_get_node()			<-- doesn't find _PCT

	goto err_out;							<-- modprobe xen-acpi-processor fails


The CPU in question is:
Intel(R) Xeon(R) CPU L5640

ACPI DSDT.dsl is here:
http://pasik.reaktio.net/dell-r510-acpi-dsdt.dsl

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Thu, Mar 07, 2013 at 09:48:08AM +0200, Pasi Kärkkäinen wrote:
> On Wed, Mar 06, 2013 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > 
> > > > Actually the correct path is: /sys/firmware/acpi/tables/DSDT
> > > > So the acpi tables are there.
> > > > 
> > > > .. but the problem is there's no _PCT info in them.
> > > > 
> > > 
> > > .. so on which hardware is xen-acpi-processor driver required? 
> > > 
> > > Is the actual problem that I don't have _PCT because it's not required/supported on my hw,
> > > and thus I don't need the whole xen-acpi-processor driver? 
> > > 
> > > I checked the Xeon 5600 CPU, and also Ivy Bridge i7, and there's no _PCT on either one..
> > 
> > I always forget which of _P* are important. I think _PPC, _PSS and _PCD
> > are the crucial ones. The _PCT is the thermal one - which I think are usually
> > found on laptops.
> > 
> 
> I don't seem to have _PCT on my Ivy Bridge i7 laptop.. 
> 
> > In your case then .. lets go back to the start - the driver failed with -EIO
> > and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
> > I can take a look at this.
> > 
> 
> Ok.
> 
> So the problem for me with Linux 3.4.32 kernel is "modprobe xen-acpi-processor" fails:
> initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> 

Great :-( On my box (SandyBridge i3 2100, MS-7680) it installs just fine. This is
v3.4.22 with 

cat linux-build/.config|grep PROCESSOR
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_XEN_ACPI_PROCESSOR=m


> The error deeper down in the ACPI internals is:
> processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable

I think looking at the code, that even on baremetal you would not have
any P-states.

I am looking at the code, and the one thing that caught my eye is this comment:

/*
 * Do a quick check if the systems looks like it should use ACPI
 * cpufreq. We look at a _PCT method being available, but don't
 * do a whole lot of sanity checks.
 */

And since your machine has no _PCT, it just bypasses it.

Is there a BIOS option for power saving? Perhaps its off? 
> 
> Function call path is this:
> 
> xen_acpi_processor_init()
> 	acpi_processor_register_performance(perf, i) 			<-- returns -EIO
> 		acpi_processor_get_performance_info(pr)			<-- returns -ENODEV and prints the error to dmesg
> 			acpi_get_handle(pr->handle, "_PCT", &handle);	
> 				acpi_ns_get_node()			<-- doesn't find _PCT
> 
> 	goto err_out;							<-- modprobe xen-acpi-processor fails
> 
> 
> The CPU in question is:
> Intel(R) Xeon(R) CPU L5640
> 
> ACPI DSDT.dsl is here:
> http://pasik.reaktio.net/dell-r510-acpi-dsdt.dsl

Oh wait, this is not an laptop! It is some rack-server.

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

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Fri, Mar 08, 2013 at 03:24:57PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 07, 2013 at 09:48:08AM +0200, Pasi Kärkkäinen wrote:
> > On Wed, Mar 06, 2013 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > 
> > > > > Actually the correct path is: /sys/firmware/acpi/tables/DSDT
> > > > > So the acpi tables are there.
> > > > > 
> > > > > .. but the problem is there's no _PCT info in them.
> > > > > 
> > > > 
> > > > .. so on which hardware is xen-acpi-processor driver required? 
> > > > 
> > > > Is the actual problem that I don't have _PCT because it's not required/supported on my hw,
> > > > and thus I don't need the whole xen-acpi-processor driver? 
> > > > 
> > > > I checked the Xeon 5600 CPU, and also Ivy Bridge i7, and there's no _PCT on either one..
> > > 
> > > I always forget which of _P* are important. I think _PPC, _PSS and _PCD
> > > are the crucial ones. The _PCT is the thermal one - which I think are usually
> > > found on laptops.
> > > 
> > 
> > I don't seem to have _PCT on my Ivy Bridge i7 laptop.. 
> > 
> > > In your case then .. lets go back to the start - the driver failed with -EIO
> > > and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
> > > I can take a look at this.
> > > 
> > 
> > Ok.
> > 
> > So the problem for me with Linux 3.4.32 kernel is "modprobe xen-acpi-processor" fails:
> > initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> > 
> 
> Great :-( On my box (SandyBridge i3 2100, MS-7680) it installs just fine. This is
> v3.4.22 with 
> 
> cat linux-build/.config|grep PROCESSOR
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> CONFIG_XEN_ACPI_PROCESSOR=m
> 

I'm using:

CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_XEN_ACPI_PROCESSOR=m


> 
> > The error deeper down in the ACPI internals is:
> > processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable
> 
> I think looking at the code, that even on baremetal you would not have
> any P-states.
> 
> I am looking at the code, and the one thing that caught my eye is this comment:
> 
> /*
>  * Do a quick check if the systems looks like it should use ACPI
>  * cpufreq. We look at a _PCT method being available, but don't
>  * do a whole lot of sanity checks.
>  */
> 
> And since your machine has no _PCT, it just bypasses it.
> 
> Is there a BIOS option for power saving? Perhaps its off? 
>

Hmm, good question, I'll have to check.. 


> > 
> > Function call path is this:
> > 
> > xen_acpi_processor_init()
> > 	acpi_processor_register_performance(perf, i) 			<-- returns -EIO
> > 		acpi_processor_get_performance_info(pr)			<-- returns -ENODEV and prints the error to dmesg
> > 			acpi_get_handle(pr->handle, "_PCT", &handle);	
> > 				acpi_ns_get_node()			<-- doesn't find _PCT
> > 
> > 	goto err_out;							<-- modprobe xen-acpi-processor fails
> > 
> > 
> > The CPU in question is:
> > Intel(R) Xeon(R) CPU L5640
> > 
> > ACPI DSDT.dsl is here:
> > http://pasik.reaktio.net/dell-r510-acpi-dsdt.dsl
> 
> Oh wait, this is not an laptop! It is some rack-server.
> 

Correct. It's a Dell R510 rack server.

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Sat, Mar 09, 2013 at 12:18:20AM +0200, Pasi Kärkkäinen wrote:
> > > 
> > > I don't seem to have _PCT on my Ivy Bridge i7 laptop.. 
> > > 
> > > > In your case then .. lets go back to the start - the driver failed with -EIO
> > > > and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
> > > > I can take a look at this.
> > > > 
> > > 
> > > Ok.
> > > 
> > > So the problem for me with Linux 3.4.32 kernel is "modprobe xen-acpi-processor" fails:
> > > initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> > > 
> > 
> > Great :-( On my box (SandyBridge i3 2100, MS-7680) it installs just fine. This is
> > v3.4.22 with 
> > 
> > cat linux-build/.config|grep PROCESSOR
> > CONFIG_ACPI_PROCESSOR=y
> > CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> > CONFIG_XEN_ACPI_PROCESSOR=m
> > 
> 
> I'm using:
> 
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> CONFIG_XEN_ACPI_PROCESSOR=m
> 

Do you see _PCT on your SandyBridge i3 DSDT? 

> 
> > 
> > > The error deeper down in the ACPI internals is:
> > > processor_perflib-0430 [00] processor_get_performa: ACPI-based processor performance control unavailable
> > 
> > I think looking at the code, that even on baremetal you would not have
> > any P-states.
> > 
> > I am looking at the code, and the one thing that caught my eye is this comment:
> > 
> > /*
> >  * Do a quick check if the systems looks like it should use ACPI
> >  * cpufreq. We look at a _PCT method being available, but don't
> >  * do a whole lot of sanity checks.
> >  */
> > 
> > And since your machine has no _PCT, it just bypasses it.
> > 
> > Is there a BIOS option for power saving? Perhaps its off? 
> >
> 
> Hmm, good question, I'll have to check.. 
>

My Dell R510 BIOS has these settings:

Turbo Mode: Enabled.
C States: Enabled.
Power Management: "Active Power Controller".

Other options for "Power Management" include: "Custom", "OS Control" and "Maximum Performance".

I tried changing it to "OS Control", but then "modprobe xen-acpi-processor" gives error -19, "No such device".


> 
> > > 
> > > Function call path is this:
> > > 
> > > xen_acpi_processor_init()
> > > 	acpi_processor_register_performance(perf, i) 			<-- returns -EIO
> > > 		acpi_processor_get_performance_info(pr)			<-- returns -ENODEV and prints the error to dmesg
> > > 			acpi_get_handle(pr->handle, "_PCT", &handle);	
> > > 				acpi_ns_get_node()			<-- doesn't find _PCT
> > > 
> > > 	goto err_out;							<-- modprobe xen-acpi-processor fails
> > > 
> > > 
> > > The CPU in question is:
> > > Intel(R) Xeon(R) CPU L5640
> > > 
> > > ACPI DSDT.dsl is here:
> > > http://pasik.reaktio.net/dell-r510-acpi-dsdt.dsl
> > 
> > Oh wait, this is not an laptop! It is some rack-server.
> > 
> 
> Correct. It's a Dell R510 rack server.
> 

Did you mean that xen-acpi-processor driver is not needed on servers? 


-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Tue, Mar 12, 2013 at 10:51:18PM +0200, Pasi Kärkkäinen wrote:
> On Sat, Mar 09, 2013 at 12:18:20AM +0200, Pasi Kärkkäinen wrote:
> > > > 
> > > > I don't seem to have _PCT on my Ivy Bridge i7 laptop.. 
> > > > 
> > > > > In your case then .. lets go back to the start - the driver failed with -EIO
> > > > > and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
> > > > > I can take a look at this.
> > > > > 
> > > > 
> > > > Ok.
> > > > 
> > > > So the problem for me with Linux 3.4.32 kernel is "modprobe xen-acpi-processor" fails:
> > > > initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> > > > 
> > > 
> > > Great :-( On my box (SandyBridge i3 2100, MS-7680) it installs just fine. This is
> > > v3.4.22 with 
> > > 
> > > cat linux-build/.config|grep PROCESSOR
> > > CONFIG_ACPI_PROCESSOR=y
> > > CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> > > CONFIG_XEN_ACPI_PROCESSOR=m
> > > 
> > 
> > I'm using:
> > 
> > CONFIG_ACPI_PROCESSOR=y
> > CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> > CONFIG_XEN_ACPI_PROCESSOR=m
> > 
> 
> Do you see _PCT on your SandyBridge i3 DSDT? 

No. I am actually not seeing a lot of them, but I am still seeing P-states?!

15:03:49 # 21 :/sys/firmware/acpi/tables/ 
> xenpm get-cpufreq-para 0
cpu id               : 0
affected_cpus        : 0
cpuinfo frequency    : max [3100000] min [1600000] cur [1600000]
scaling_driver       : acpi-cpufreq
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 3100000 3000000 2900000 2800000 2700000 2600000 2500000 2400000 2300000 2200000 2100000 2000000 1900000 1800000 1700000 *1600000
scaling frequency    : max [3100000] min [1600000] cur [1600000]

WTF!?

And also the C-states:
> xenpm get-cpuidle-states 0
Max possible C-state: C7

cpu id               : 0
total C-states       : 3
idle time(ms)        : 543153
C0                   : transition [               45047]
                       residency  [               11006 ms]
C1                   : transition [               14099]
                       residency  [               13076 ms]
C2                   : transition [               30948]
                       residency  [              527658 ms]
pc2                  : [               13698 ms]
pc3                  : [                   0 ms]
pc6                  : [              484534 ms]
pc7                  : [                   0 ms]
cc3                  : [                   0 ms]
cc6                  : [              525300 ms]
cc7                  : [                   0 ms]

I need to look back at my notes on how the _PCT, _PSS, _Pwhatevername
work.

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Fri, Mar 15, 2013 at 11:05:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 12, 2013 at 10:51:18PM +0200, Pasi Kärkkäinen wrote:
> > On Sat, Mar 09, 2013 at 12:18:20AM +0200, Pasi Kärkkäinen wrote:
> > > > > 
> > > > > I don't seem to have _PCT on my Ivy Bridge i7 laptop.. 
> > > > > 
> > > > > > In your case then .. lets go back to the start - the driver failed with -EIO
> > > > > > and it was v3.4.x kernel? Now that I've figured out the regression with v3.9
> > > > > > I can take a look at this.
> > > > > > 
> > > > > 
> > > > > Ok.
> > > > > 
> > > > > So the problem for me with Linux 3.4.32 kernel is "modprobe xen-acpi-processor" fails:
> > > > > initcall xen_acpi_processor_init+0x0/0x6b0 [xen_acpi_processor] returned with error code -5
> > > > > 
> > > > 
> > > > Great :-( On my box (SandyBridge i3 2100, MS-7680) it installs just fine. This is
> > > > v3.4.22 with 
> > > > 
> > > > cat linux-build/.config|grep PROCESSOR
> > > > CONFIG_ACPI_PROCESSOR=y
> > > > CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> > > > CONFIG_XEN_ACPI_PROCESSOR=m
> > > > 
> > > 
> > > I'm using:
> > > 
> > > CONFIG_ACPI_PROCESSOR=y
> > > CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
> > > CONFIG_XEN_ACPI_PROCESSOR=m
> > > 
> > 
> > Do you see _PCT on your SandyBridge i3 DSDT? 
> 
> No. I am actually not seeing a lot of them, but I am still seeing P-states?!
>

OK, good. I'm not the only one who doesn't see _PCT :)

 
> 15:03:49 # 21 :/sys/firmware/acpi/tables/ 
> > xenpm get-cpufreq-para 0
> cpu id               : 0
> affected_cpus        : 0
> cpuinfo frequency    : max [3100000] min [1600000] cur [1600000]
> scaling_driver       : acpi-cpufreq
> scaling_avail_gov    : userspace performance powersave ondemand
> current_governor     : ondemand
>   ondemand specific  :
>     sampling_rate    : max [10000000] min [10000] cur [20000]
>     up_threshold     : 80
> scaling_avail_freq   : 3100000 3000000 2900000 2800000 2700000 2600000 2500000 2400000 2300000 2200000 2100000 2000000 1900000 1800000 1700000 *1600000
> scaling frequency    : max [3100000] min [1600000] cur [1600000]
> 
> WTF!?
> 

On my server:

# xenpm get-cpufreq-para 0
[CPU0] failed to get cpufreq parameter


> And also the C-states:
> > xenpm get-cpuidle-states 0
> Max possible C-state: C7
> 
> cpu id               : 0
> total C-states       : 3
> idle time(ms)        : 543153
> C0                   : transition [               45047]
>                        residency  [               11006 ms]
> C1                   : transition [               14099]
>                        residency  [               13076 ms]
> C2                   : transition [               30948]
>                        residency  [              527658 ms]
> pc2                  : [               13698 ms]
> pc3                  : [                   0 ms]
> pc6                  : [              484534 ms]
> pc7                  : [                   0 ms]
> cc3                  : [                   0 ms]
> cc6                  : [              525300 ms]
> cc7                  : [                   0 ms]
> 

# xenpm get-cpuidle-states 0
Max possible C-state: C7

cpu id               : 0
total C-states       : 2
idle time(ms)        : 418428
C0                   : transition [                   1]
                       residency  [                1526 ms]
C1                   : transition [                   1]
                       residency  [              418428 ms]
pc2                  : [                   0 ms]
pc3                  : [                   0 ms]
pc6                  : [                   0 ms]
pc7                  : [                   0 ms]
cc3                  : [                   0 ms]
cc6                  : [                   0 ms]
cc7                  : [                   0 ms]



> I need to look back at my notes on how the _PCT, _PSS, _Pwhatevername
> work.
>

Yep. Does xen-acpi-processor driver load OK on your servers? 


-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Fri, Mar 15, 2013 at 05:19:34PM +0200, Pasi Kärkkäinen wrote:
> 
> > I need to look back at my notes on how the _PCT, _PSS, _Pwhatevername
> > work.
> >
> 
> Yep. Does xen-acpi-processor driver load OK on your servers? 
> 

I just tried Linux 3.8.3 as dom0 on the Xeon 5600 CPU and xen-acpi-processor fails 
in the same way as it fails with Linux 3.4.

I also tested on my Ivy Bridge i7 desktop, and there xen-acpi-processor driver loads OK..


-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Fri, Mar 15, 2013 at 09:37:06PM +0200, Pasi Kärkkäinen wrote:
> On Fri, Mar 15, 2013 at 05:19:34PM +0200, Pasi Kärkkäinen wrote:
> > 
> > > I need to look back at my notes on how the _PCT, _PSS, _Pwhatevername
> > > work.
> > >
> > 
> > Yep. Does xen-acpi-processor driver load OK on your servers? 
> > 
> 
> I just tried Linux 3.8.3 as dom0 on the Xeon 5600 CPU and xen-acpi-processor fails 
> in the same way as it fails with Linux 3.4.
> 
> I also tested on my Ivy Bridge i7 desktop, and there xen-acpi-processor driver loads OK..

And when I add some extra printks in working box I see that these calls:

	acpi_get_handle(pr->handle, "_PCT", &handle);
	acpi_get_handle(pr->handle, "_PSD", &handle);
	acpi_get_handle(pr->handle, "_PSS", &handle);

work, yet in the SSDT and DSDT those strings don't show up? I think this
requires some deep ACPI sorcery to figure out. On the AMD boxes they
nicely show up.

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Fri, Mar 15, 2013 at 05:15:18PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 15, 2013 at 09:37:06PM +0200, Pasi Kärkkäinen wrote:
> > On Fri, Mar 15, 2013 at 05:19:34PM +0200, Pasi Kärkkäinen wrote:
> > > 
> > > > I need to look back at my notes on how the _PCT, _PSS, _Pwhatevername
> > > > work.
> > > >
> > > 
> > > Yep. Does xen-acpi-processor driver load OK on your servers? 
> > > 
> > 
> > I just tried Linux 3.8.3 as dom0 on the Xeon 5600 CPU and xen-acpi-processor fails 
> > in the same way as it fails with Linux 3.4.
> > 
> > I also tested on my Ivy Bridge i7 desktop, and there xen-acpi-processor driver loads OK..
> 
> And when I add some extra printks in working box I see that these calls:
> 
> 	acpi_get_handle(pr->handle, "_PCT", &handle);
> 	acpi_get_handle(pr->handle, "_PSD", &handle);
> 	acpi_get_handle(pr->handle, "_PSS", &handle);
> 
> work, yet in the SSDT and DSDT those strings don't show up?
>

That's weird.. then again it probably explains why I didn't see 
those strings either in SSDT/DSDT on the i7 boxes.

> I think this
> requires some deep ACPI sorcery to figure out. On the AMD boxes they
> nicely show up.
>

Yeah I was afraid of that ;)

I've already tried simple things with acpi.debug_level=0xffffffff and acpi.debug_layer=0xffffffff
but nothing obvious so far.. I need to dig deeper..

It'd help to understand how all that SSDT/DSDT and PCT/PSD/PSS stuff is supposed to work.. 
If you happen to have good links to read about this ACPI black magic let me know (I'll probably regret asking for this ;)

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

> > > I also tested on my Ivy Bridge i7 desktop, and there xen-acpi-processor driver loads OK..
> > 
> > And when I add some extra printks in working box I see that these calls:
> > 
> > 	acpi_get_handle(pr->handle, "_PCT", &handle);
> > 	acpi_get_handle(pr->handle, "_PSD", &handle);
> > 	acpi_get_handle(pr->handle, "_PSS", &handle);
> > 
> > work, yet in the SSDT and DSDT those strings don't show up?
> >
> 
> That's weird.. then again it probably explains why I didn't see 
> those strings either in SSDT/DSDT on the i7 boxes.
> 
> > I think this
> > requires some deep ACPI sorcery to figure out. On the AMD boxes they
> > nicely show up.
> >
> 
> Yeah I was afraid of that ;)
> 
> I've already tried simple things with acpi.debug_level=0xffffffff and acpi.debug_layer=0xffffffff
> but nothing obvious so far.. I need to dig deeper..
> 
> It'd help to understand how all that SSDT/DSDT and PCT/PSD/PSS stuff is supposed to work.. 
> If you happen to have good links to read about this ACPI black magic let me know (I'll probably regret asking for this ;)

I've been using a combination of 
http://www.plasma-online.de/index.html?content=http%3A//www.plasma-online.de/english/identify/serial/pnp_id_pnp.html

and the DSDT to eliminate all of the entries that are not relevant to
power-states. Also, the P-states (and C-states) are all within
the:
 Scope (\_PR)                                                                
    {                                                                           
    ..
    }

that.

Also the ACPI spec - I took a look at the PCT, PSD, and PSS and what
kind of information they are suppose to contain (which is pretty much
just an structure of some data). There is also the _OSC method in ACPI
which is to be executed by the ACPI AML, and by executing said method
then the _PCT, _PSD, _PSS, etc are suppose to appear in the ACPI
namespace.

I also look at coreboot, since it has a bunch of AMLs and comments.
Especially src/cpu/intel/haswell/acpi.c

.. There is a ton of interesting stuff there:
src/cpu/intel/turbo/turbo.c or src/northbridge/intel/sandybridge

Anywho, back to the DSDT, which on my box shows:


    Scope (_PR)
    {
        OperationRegion (SSDT, SystemMemory, 0xBAE0AC18, 0x038C)
        OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084)
        Name (NCST, 0x02)
        Name (NPSS, 0x10)
        Name (HNDL, 0x80000000)
        Name (CHDL, 0x80000000)
        Name (TNLP, 0x0004)
        Name (CINT, Zero)
        Name (PDCV, 0xFFFFFFFF)
        Name (APSS, Package (0x10)
        {
            Package (0x06)
            {
                0x0C1C, 
                0x0000FDE8, 
                0x000A, 
                0x000A, 
                0x1F00, 
                0x1F00
            }, 
.. snip..

        Method (OSC, 4, NotSerialized)
        {
            CreateDWordField (Arg3, Zero, STS)
            CreateDWordField (Arg3, 0x04, CAP)
            CreateDWordField (Arg0, Zero, IID0)
            CreateDWordField (Arg0, 0x04, IID1)
            CreateDWordField (Arg0, 0x08, IID2)
            CreateDWordField (Arg0, 0x0C, IID3)
            Name (UID0, Buffer (0x10)
            {
                /* 0000 */    0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 
                /* 0008 */    0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53
            })
            CreateDWordField (UID0, Zero, EID0)
            CreateDWordField (UID0, 0x04, EID1)
            CreateDWordField (UID0, 0x08, EID2)
            CreateDWordField (UID0, 0x0C, EID3)
            If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), 
                LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3)))))
            {
                Store (0x06, Index (STS, Zero))
                Return (Arg3)
            }

            And (PDCV, CAP, PDCV)
            If (LEqual (CINT, Zero))
            {
                Store (One, CINT)
                If (LEqual (And (PDCV, 0x09), 0x09))
                {
                    If (LNotEqual (NPSS, Zero))
                    {
                        Load (SSDT, HNDL)
                    }
                }

                If (LEqual (And (PDCV, 0x10), 0x10))
                {
                    If (LNotEqual (NCST, 0xFF))
                    {
                        Load (CSDT, CHDL)
                    }
                }
            }

            Return (Arg3)
        }
    }

Which looks to load an new SSDT or CSDT. Looking back at your DSDT -
which BTW has tons of debug usage:

                    Store ("Platform _OSC, APEI is implementend", Debug)
should make it easier to narrow it down.

You don't appear to have any Load method, so perhaps you have some
SSDTs. If you look at those (there can be many), that might help.
Again, you are looking at \_PR scope.

On my box, I took the SSDT but it did not give any insight, except that
the _PDC and _OSC end up calling in the  \_PR.OSC method pasted above:

    Scope (\_PR)                                                                
    {                                                                           
        Processor (P000, 0x01, 0x00000410, 0x06)                                
        {                             
.. snip..                                          
            Method (_OSC, 4, NotSerialized)                                     
            {                                                                   
                Return (\_PR.OSC)                                               
                Arg0                                                            
                Arg1                                                            
                Arg2                                                            
                Arg3                                                            
            }                                                                   
        }                                                                       
                                      
    }

It looks like the magic incantations are in:

        OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084)

so physical address 0xBAE0BE18. The machine is offline so it will have
to wait until I can get the contents of that physical address.

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

> On my box, I took the SSDT but it did not give any insight, except that
> the _PDC and _OSC end up calling in the  \_PR.OSC method pasted above:
> 
>     Scope (\_PR)                                                                
>     {                                                                           
>         Processor (P000, 0x01, 0x00000410, 0x06)                                
>         {                             
> .. snip..                                          
>             Method (_OSC, 4, NotSerialized)                                     
>             {                                                                   
>                 Return (\_PR.OSC)                                               
>                 Arg0                                                            
>                 Arg1                                                            
>                 Arg2                                                            
>                 Arg3                                                            
>             }                                                                   
>         }                                                                       
>                                       
>     }
> 
> It looks like the magic incantations are in:
> 
>         OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084)
> 
> so physical address 0xBAE0BE18. The machine is offline so it will have
> to wait until I can get the contents of that physical address.


And if I dug deep enough and looked in: /sys/firmware/acpi/tables/dynamic/
I would have found SSDT2 and SSDT3 and SSDT2 sure enough has:

  Scope (\_PR.P000)
    {
        Name (_PCT, Package (0x02)
        {

. .. snip..

and also the _PSS, _PPC, etc.

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Mon, Mar 18, 2013 at 09:06:59AM -0400, Konrad Rzeszutek Wilk wrote:
> > On my box, I took the SSDT but it did not give any insight, except that
> > the _PDC and _OSC end up calling in the  \_PR.OSC method pasted above:
> > 
> >     Scope (\_PR)                                                                
> >     {                                                                           
> >         Processor (P000, 0x01, 0x00000410, 0x06)                                
> >         {                             
> > .. snip..                                          
> >             Method (_OSC, 4, NotSerialized)                                     
> >             {                                                                   
> >                 Return (\_PR.OSC)                                               
> >                 Arg0                                                            
> >                 Arg1                                                            
> >                 Arg2                                                            
> >                 Arg3                                                            
> >             }                                                                   
> >         }                                                                       
> >                                       
> >     }
> > 
> > It looks like the magic incantations are in:
> > 
> >         OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084)
> > 
> > so physical address 0xBAE0BE18. The machine is offline so it will have
> > to wait until I can get the contents of that physical address.
> 
> 
> And if I dug deep enough and looked in: /sys/firmware/acpi/tables/dynamic/
> I would have found SSDT2 and SSDT3 and SSDT2 sure enough has:
> 
>   Scope (\_PR.P000)
>     {
>         Name (_PCT, Package (0x02)
>         {
> 
> . .. snip..
> 
> and also the _PSS, _PPC, etc.
>

Hmm, on the R510 server where xen-acpi-processor doesn't work 
/sys/firmware/acpi/tables/dynamic/ is empty.. 

-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Mon, Mar 18, 2013 at 07:02:42PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Mar 18, 2013 at 09:06:59AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On my box, I took the SSDT but it did not give any insight, except that
> > > the _PDC and _OSC end up calling in the  \_PR.OSC method pasted above:
> > > 
> > >     Scope (\_PR)                                                                
> > >     {                                                                           
> > >         Processor (P000, 0x01, 0x00000410, 0x06)                                
> > >         {                             
> > > .. snip..                                          
> > >             Method (_OSC, 4, NotSerialized)                                     
> > >             {                                                                   
> > >                 Return (\_PR.OSC)                                               
> > >                 Arg0                                                            
> > >                 Arg1                                                            
> > >                 Arg2                                                            
> > >                 Arg3                                                            
> > >             }                                                                   
> > >         }                                                                       
> > >                                       
> > >     }
> > > 
> > > It looks like the magic incantations are in:
> > > 
> > >         OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084)
> > > 
> > > so physical address 0xBAE0BE18. The machine is offline so it will have
> > > to wait until I can get the contents of that physical address.
> > 
> > 
> > And if I dug deep enough and looked in: /sys/firmware/acpi/tables/dynamic/
> > I would have found SSDT2 and SSDT3 and SSDT2 sure enough has:
> > 
> >   Scope (\_PR.P000)
> >     {
> >         Name (_PCT, Package (0x02)
> >         {
> > 
> > . .. snip..
> > 
> > and also the _PSS, _PPC, etc.
> >
> 
> Hmm, on the R510 server where xen-acpi-processor doesn't work 
> /sys/firmware/acpi/tables/dynamic/ is empty.. 

Pfff.. And 'cpuinfo' or 'cpufreq-info' when you boot baremetal gives
you different P-states?

If so, is the DSDT different that when running under Xen? And
lasty, does it create any SSDT in the dynamic directory?

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Mon, Mar 18, 2013 at 04:20:51PM -0400, Konrad Rzeszutek Wilk wrote:
> > 
> > Hmm, on the R510 server where xen-acpi-processor doesn't work 
> > /sys/firmware/acpi/tables/dynamic/ is empty.. 
> 
> Pfff.. And 'cpuinfo' or 'cpufreq-info' when you boot baremetal gives
> you different P-states?
> 
> If so, is the DSDT different that when running under Xen? And
> lasty, does it create any SSDT in the dynamic directory?
>

Finally I figured this one out.. in the end it was a BIOS settings/configuration issue.

I found this: http://en.community.dell.com/techcenter/power-cooling/w/wiki/best-practices-in-power-management.aspx

So I had to enable "OS Control" for "Power Management" in the Dell server BIOS,
and after that the CPU P-states are available in the ACPI tables, 
and xen-acpi-processor driver loads and works OK in the dom0 kernel!

(I'm almost 100% certain I tried that option already earlier,
so I don't have any idea why it didn't work back then.. but *now* it seems to work!)

For reference I'm using Intel L5640 Xeon CPU, and here's xenpm output for it:

# xenpm get-cpufreq-states

cpu id               : 0
total P-states       : 7
usable P-states      : 7
current frequency    : 1596 MHz
P0         [2262 MHz]: transition [                   5]
                       residency  [                  59 ms]
P1         [2261 MHz]: transition [                   0]
                       residency  [                   0 ms]
P2         [2128 MHz]: transition [                   0]
                       residency  [                   0 ms]
P3         [1995 MHz]: transition [                   0]
                       residency  [                   0 ms]
P4         [1862 MHz]: transition [                   0]
                       residency  [                   0 ms]
P5         [1729 MHz]: transition [                   0]
                       residency  [                   0 ms]
*P6        [1596 MHz]: transition [                   5]
                       residency  [                3437 ms]

cpu id               : 1
total P-states       : 7
usable P-states      : 7
current frequency    : 1596 MHz
P0         [2262 MHz]: transition [                   4]
                       residency  [                 103 ms]
P1         [2261 MHz]: transition [                   0]
                       residency  [                   0 ms]
P2         [2128 MHz]: transition [                   0]
                       residency  [                   0 ms]
P3         [1995 MHz]: transition [                   0]
                       residency  [                   0 ms]
P4         [1862 MHz]: transition [                   0]
                       residency  [                   0 ms]
P5         [1729 MHz]: transition [                   0]
                       residency  [                   0 ms]
*P6        [1596 MHz]: transition [                   4]
                       residency  [                5893 ms]

.. and so on.


Thanks a lot Konrad for your help on this!


-- Pasi

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Konrad Rzeszutek Wilk]

On Sun, May 12, 2013 at 07:51:26PM +0300, Pasi Kärkkäinen wrote:
> On Mon, Mar 18, 2013 at 04:20:51PM -0400, Konrad Rzeszutek Wilk wrote:
> > > 
> > > Hmm, on the R510 server where xen-acpi-processor doesn't work 
> > > /sys/firmware/acpi/tables/dynamic/ is empty.. 
> > 
> > Pfff.. And 'cpuinfo' or 'cpufreq-info' when you boot baremetal gives
> > you different P-states?
> > 
> > If so, is the DSDT different that when running under Xen? And
> > lasty, does it create any SSDT in the dynamic directory?
> >
> 
> Finally I figured this one out.. in the end it was a BIOS settings/configuration issue.
> 
> I found this: http://en.community.dell.com/techcenter/power-cooling/w/wiki/best-practices-in-power-management.aspx
> 
> So I had to enable "OS Control" for "Power Management" in the Dell server BIOS,
> and after that the CPU P-states are available in the ACPI tables, 
> and xen-acpi-processor driver loads and works OK in the dom0 kernel!

Aah, right. That would explain it.
> 
> (I'm almost 100% certain I tried that option already earlier,
> so I don't have any idea why it didn't work back then.. but *now* it seems to work!)
> 
> For reference I'm using Intel L5640 Xeon CPU, and here's xenpm output for it:
> 
> # xenpm get-cpufreq-states
> 
> cpu id               : 0
> total P-states       : 7
> usable P-states      : 7
> current frequency    : 1596 MHz
> P0         [2262 MHz]: transition [                   5]
>                        residency  [                  59 ms]

Woot! Turbo Mode!

> P1         [2261 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P2         [2128 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P3         [1995 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P4         [1862 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P5         [1729 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> *P6        [1596 MHz]: transition [                   5]
>                        residency  [                3437 ms]
> 
> cpu id               : 1
> total P-states       : 7
> usable P-states      : 7
> current frequency    : 1596 MHz
> P0         [2262 MHz]: transition [                   4]
>                        residency  [                 103 ms]
> P1         [2261 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P2         [2128 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P3         [1995 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P4         [1862 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> P5         [1729 MHz]: transition [                   0]
>                        residency  [                   0 ms]
> *P6        [1596 MHz]: transition [                   4]
>                        residency  [                5893 ms]
> 
> .. and so on.
> 
> 
> Thanks a lot Konrad for your help on this!

Sure thing, thought you found the resolution so the credit is due you.
> 
> 
> -- Pasi
> 

Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error

[Pasi Kärkkäinen]

On Mon, May 13, 2013 at 09:46:10AM -0400, Konrad Rzeszutek Wilk wrote:
> > 
> > (I'm almost 100% certain I tried that option already earlier,
> > so I don't have any idea why it didn't work back then.. but *now* it seems to work!)
> > 
> > For reference I'm using Intel L5640 Xeon CPU, and here's xenpm output for it:
> > 
> > # xenpm get-cpufreq-states
> > 
> > cpu id               : 0
> > total P-states       : 7
> > usable P-states      : 7
> > current frequency    : 1596 MHz
> > P0         [2262 MHz]: transition [                   5]
> >                        residency  [                  59 ms]
> 
> Woot! Turbo Mode!
>

Yep, turbo seems to work..

# xenpm get-cpufreq-para

cpu id               : 0
affected_cpus        : 0
cpuinfo frequency    : max [2262000] min [1596000] cur [2262000]
scaling_driver       : acpi-cpufreq
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2262000 2261000 2128000 1995000 1862000 1729000 *1596000
scaling frequency    : max [2262000] min [1596000] cur [1596000]
turbo mode           : enabled

.. 


-- Pasi