* Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error @ 2013-02-21 9:24 Pasi Kärkkäinen 2013-02-21 12:29 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-02-21 9:24 UTC (permalink / raw) To: xen-devel; +Cc: David Vrabel, Konrad Rzeszutek Wilk 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-02-21 9:24 Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error Pasi Kärkkäinen @ 2013-02-21 12:29 ` Konrad Rzeszutek Wilk 2013-02-21 12:42 ` Pasi Kärkkäinen 2013-02-24 22:05 ` Pasi Kärkkäinen 0 siblings, 2 replies; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-02-21 12:29 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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 > ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-02-21 12:29 ` Konrad Rzeszutek Wilk @ 2013-02-21 12:42 ` Pasi Kärkkäinen 2013-02-25 17:03 ` Konrad Rzeszutek Wilk 2013-02-24 22:05 ` Pasi Kärkkäinen 1 sibling, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-02-21 12:42 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-02-21 12:42 ` Pasi Kärkkäinen @ 2013-02-25 17:03 ` Konrad Rzeszutek Wilk 2013-02-25 19:08 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-02-25 17:03 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-02-25 17:03 ` Konrad Rzeszutek Wilk @ 2013-02-25 19:08 ` Pasi Kärkkäinen 0 siblings, 0 replies; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-02-25 19:08 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-02-21 12:29 ` Konrad Rzeszutek Wilk 2013-02-21 12:42 ` Pasi Kärkkäinen @ 2013-02-24 22:05 ` Pasi Kärkkäinen 2013-03-03 18:53 ` Pasi Kärkkäinen 1 sibling, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-02-24 22:05 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-02-24 22:05 ` Pasi Kärkkäinen @ 2013-03-03 18:53 ` Pasi Kärkkäinen 2013-03-05 17:45 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-03 18:53 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-03 18:53 ` Pasi Kärkkäinen @ 2013-03-05 17:45 ` Konrad Rzeszutek Wilk 2013-03-06 20:41 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-05 17:45 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-05 17:45 ` Konrad Rzeszutek Wilk @ 2013-03-06 20:41 ` Pasi Kärkkäinen 2013-03-06 21:01 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-06 20:41 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-06 20:41 ` Pasi Kärkkäinen @ 2013-03-06 21:01 ` Pasi Kärkkäinen 2013-03-06 21:21 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-06 21:01 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-06 21:01 ` Pasi Kärkkäinen @ 2013-03-06 21:21 ` Pasi Kärkkäinen 2013-03-07 0:29 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-06 21:21 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-06 21:21 ` Pasi Kärkkäinen @ 2013-03-07 0:29 ` Konrad Rzeszutek Wilk 2013-03-07 7:48 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-07 0:29 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-07 0:29 ` Konrad Rzeszutek Wilk @ 2013-03-07 7:48 ` Pasi Kärkkäinen 2013-03-08 20:24 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-07 7:48 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-07 7:48 ` Pasi Kärkkäinen @ 2013-03-08 20:24 ` Konrad Rzeszutek Wilk 2013-03-08 22:18 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-08 20:24 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-08 20:24 ` Konrad Rzeszutek Wilk @ 2013-03-08 22:18 ` Pasi Kärkkäinen 2013-03-12 20:51 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-08 22:18 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-08 22:18 ` Pasi Kärkkäinen @ 2013-03-12 20:51 ` Pasi Kärkkäinen 2013-03-15 15:05 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-12 20:51 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-12 20:51 ` Pasi Kärkkäinen @ 2013-03-15 15:05 ` Konrad Rzeszutek Wilk 2013-03-15 15:19 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-15 15:05 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-15 15:05 ` Konrad Rzeszutek Wilk @ 2013-03-15 15:19 ` Pasi Kärkkäinen 2013-03-15 19:37 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-15 15:19 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-15 15:19 ` Pasi Kärkkäinen @ 2013-03-15 19:37 ` Pasi Kärkkäinen 2013-03-15 21:15 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-15 19:37 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-15 19:37 ` Pasi Kärkkäinen @ 2013-03-15 21:15 ` Konrad Rzeszutek Wilk 2013-03-15 21:32 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-15 21:15 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-15 21:15 ` Konrad Rzeszutek Wilk @ 2013-03-15 21:32 ` Pasi Kärkkäinen 2013-03-17 17:00 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-15 21:32 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-15 21:32 ` Pasi Kärkkäinen @ 2013-03-17 17:00 ` Konrad Rzeszutek Wilk 2013-03-18 13:06 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-17 17:00 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel > > > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-17 17:00 ` Konrad Rzeszutek Wilk @ 2013-03-18 13:06 ` Konrad Rzeszutek Wilk 2013-03-18 17:02 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-18 13:06 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-18 13:06 ` Konrad Rzeszutek Wilk @ 2013-03-18 17:02 ` Pasi Kärkkäinen 2013-03-18 20:20 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-03-18 17:02 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-18 17:02 ` Pasi Kärkkäinen @ 2013-03-18 20:20 ` Konrad Rzeszutek Wilk 2013-05-12 16:51 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-03-18 20:20 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-03-18 20:20 ` Konrad Rzeszutek Wilk @ 2013-05-12 16:51 ` Pasi Kärkkäinen 2013-05-13 13:46 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-05-12 16:51 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-05-12 16:51 ` Pasi Kärkkäinen @ 2013-05-13 13:46 ` Konrad Rzeszutek Wilk 2013-05-13 15:03 ` Pasi Kärkkäinen 0 siblings, 1 reply; 28+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-05-13 13:46 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: David Vrabel, xen-devel 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error 2013-05-13 13:46 ` Konrad Rzeszutek Wilk @ 2013-05-13 15:03 ` Pasi Kärkkäinen 0 siblings, 0 replies; 28+ messages in thread From: Pasi Kärkkäinen @ 2013-05-13 15:03 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2013-05-13 15:03 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-21 9:24 Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error Pasi Kärkkäinen 2013-02-21 12:29 ` Konrad Rzeszutek Wilk 2013-02-21 12:42 ` Pasi Kärkkäinen 2013-02-25 17:03 ` Konrad Rzeszutek Wilk 2013-02-25 19:08 ` Pasi Kärkkäinen 2013-02-24 22:05 ` Pasi Kärkkäinen 2013-03-03 18:53 ` Pasi Kärkkäinen 2013-03-05 17:45 ` Konrad Rzeszutek Wilk 2013-03-06 20:41 ` Pasi Kärkkäinen 2013-03-06 21:01 ` Pasi Kärkkäinen 2013-03-06 21:21 ` Pasi Kärkkäinen 2013-03-07 0:29 ` Konrad Rzeszutek Wilk 2013-03-07 7:48 ` Pasi Kärkkäinen 2013-03-08 20:24 ` Konrad Rzeszutek Wilk 2013-03-08 22:18 ` Pasi Kärkkäinen 2013-03-12 20:51 ` Pasi Kärkkäinen 2013-03-15 15:05 ` Konrad Rzeszutek Wilk 2013-03-15 15:19 ` Pasi Kärkkäinen 2013-03-15 19:37 ` Pasi Kärkkäinen 2013-03-15 21:15 ` Konrad Rzeszutek Wilk 2013-03-15 21:32 ` Pasi Kärkkäinen 2013-03-17 17:00 ` Konrad Rzeszutek Wilk 2013-03-18 13:06 ` Konrad Rzeszutek Wilk 2013-03-18 17:02 ` Pasi Kärkkäinen 2013-03-18 20:20 ` Konrad Rzeszutek Wilk 2013-05-12 16:51 ` Pasi Kärkkäinen 2013-05-13 13:46 ` Konrad Rzeszutek Wilk 2013-05-13 15:03 ` Pasi Kärkkäinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.