Carsten Schiers
2011-Jun-11 09:25 UTC
AW: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
I switched on ACPI_DEBUG but the result is not surprising:
Jun 11 10:56:48 data kernel: [ 186.897468] nsutils-0461
[ffff880002b1db00] [00] ns_build_internal_name: Returning
[ffff88000ed14988] (rel) "_CST"
Jun 11 10:56:48 data kernel: [ 186.897473] utmutex-0257
[ffff880002b1db00] [00] ut_acquire_mutex : Thread ffff880002b1db00
attempting to acquire Mutex [ACPI_MTX_Namespace]
Jun 11 10:56:48 data kernel: [ 186.897479] osl-0872
[ffff880002b1db00] [00] os_wait_semaphore : Waiting for
semaphore[ffff88000fc2e1e0|1|65535]
Jun 11 10:56:48 data kernel: [ 186.897485] osl-0891
[ffff880002b1db00] [00] os_wait_semaphore : Acquired
semaphore[ffff88000fc2e1e0|1|65535] utmutex-0265 [ffff880002b1db00] [00]
ut_acquire_mutex : Thread ffff880002b1db00 acquired Mutex
[ACPI_MTX_Namespace]
Jun 11 10:56:48 data kernel: [ 186.897496] nsaccess-0399
[ffff880002b1db00] [00] ns_lookup : Searching relative to
prefix scope [C002] (ffff88000fc2e4a0)
Jun 11 10:56:48 data kernel: [ 186.897501] nsaccess-0511
[ffff880002b1db00] [00] ns_lookup : Simple Pathname (1
segment, Flags=2)
Jun 11 10:56:48 data kernel: [ 186.897506] nsdump-0087
[ffff880002b1db00] [00] ns_print_pathname : [_CST]
Jun 11 10:56:48 data kernel: [ 186.897515] nssearch-0114
[ffff880002b1db00] [00] ns_search_one_scope : Searching \_PR_.C002
(ffff88000fc2e4a0) For [_CST] (Untyped)
Jun 11 10:56:48 data kernel: [ 186.897521] nssearch-0179
[ffff880002b1db00] [00] ns_search_one_scope : Name [_CST] (Untyped)
not found in search in scope [C002] ffff88000fc2e4a0 first child
ffff88000fa54700
Jun 11 10:56:48 data kernel: [ 186.897528] nssearch-0390
[ffff880002b1db00] [00] ns_search_and_enter : _CST Not found in
ffff88000fc2e4a0 [Not adding]
Jun 11 10:56:48 data kernel: [ 186.897533] nsaccess-0572
[ffff880002b1db00] [00] ns_lookup : Name [_CST] not found in
scope [C002] ffff88000fc2e4a0
Jun 11 10:56:48 data kernel: [ 186.897539] nsutils-0876
[ffff880002b1db00] [00] ns_get_node : _CST, AE_NOT_FOUND
Jun 11 10:56:48 data kernel: [ 186.897544] utmutex-0299
[ffff880002b1db00] [00] ut_release_mutex : Thread ffff880002b1db00
releasing Mutex [ACPI_MTX_Namespace]
Jun 11 10:56:48 data kernel: [ 186.897549] osl-0911
[ffff880002b1db00] [00] os_signal_semaphore : Signaling
semaphore[ffff88000fc2e1e0|1]
Jun 11 10:56:48 data kernel: [ 186.897555]
acpi_processor_get_power_info_cst bad cst
Jun 11 10:56:48 data kernel: [ 186.897557] processor_idle-0363
[ffff880002b1db00] [00] processor_get_power_in: No _CST, giving up
Jun 11 10:56:48 data kernel: [ 186.897562]
acpi_processor_get_power_info result=-19, -ENODEV=-19
Jun 11 10:56:48 data kernel: [ 186.897563]
acpi_processor_get_power_info analyzes fadt
Jun 11 10:56:48 data kernel: [ 186.897565]
acpi_processor_get_power_info result=-19, -ENODEV=-19
Jun 11 10:56:48 data kernel: [ 186.897567]
acpi_processor_get_power_info we have a result
Jun 11 10:56:48 data kernel: [ 186.897569]
xen_acpi_processor_get_power_info returns=-19
Jun 11 10:56:48 data kernel: [ 186.897570]
xen_acpi_processor_power_init got power info
Jun 11 10:56:48 data kernel: [ 186.897572]
xen_acpi_processor_power_init not power flags
Jun 11 10:56:48 data kernel: [ 186.897574] scan-0568
[ffff880002b1db00] [00] bus_driver_init : Driver successfully
bound to device
Jun 11 10:56:48
It doesn''t find _CST, as we did not in the extract of acpiextract.
Unfortunately, the old, working Xen 4.1.0/Linux 2.6.18 combo doesn''t
boot any longer, because
I upgraded to Debian Squeeze already and something doesn''t work with
the
udev version. I will try to boot native Linux in order to verify 100%
that the tables
are there.
If we already assume this, the cause should be in the way how pvops
Linux is mapping the tables into the system, shouldn''t it`
Carsten.
-----Ursprüngliche Nachricht-----
Von: Yu, Ke [mailto:ke.yu@intel.com]
Gesendet: Samstag, 11. Juni 2011 09:34
An: Carsten Schiers
Betreff: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
Hi Carsten,
it is fine to include me in the loop, although I am now working in
another project.
From the info you provide, I think you are very near to the root cause,
since you already observe it is caused by _CST evaluation failure. So
the next step would be finding out what the _CST method does.
Unfortunately, I did not see _CST info in your attached tables. It is
usually in a separate table, which is loaded in DSDT/SSDTs. So you may
want to find out what exact the _CST does. Also it is good idea to
enable the ACPI_DEBUG and see what happens.
Regards
Ke
-----Original Message-----
From: Carsten Schiers [mailto:carsten@schiers.de]
Sent: Saturday, June 11, 2011 5:21 AM
To: Yu, Ke
Subject: WG: RE: RE: RE: [Xen-devel] No C-States any longer...
Hi Ke, may I put you in the loop? I saw some patches that make me think
you did the main part of the code.
I have a problem with my Gigabyte GA-M56S-S3/AMD Athlon X3 400e combo
running Xen 4.1.0 and latest pvops kernel. It does not recognize
C-States, P-States are ok. I tracked it down already to a failing call
of acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer); in
acpi_processor_get_power_info_cst()
in the file drivers/acpi/processor_idle.c.
I have attached the acpidump and disassembled files. What makes me
wonder is that the same hardware runs perfectly with Xen 4.1.0 /
Xenified linux-2.6.18.8, so I assume no BIOS error.
Tomorrow I will try to recompile the pvops kernel with ACPI_DEBUG set.
Do you have any other clue?
I also attached some dmesg which shows some printks I put in, maybe the
Thanks & BR,
Carsten.
-----Ursprüngliche Nachricht-----
Von: Carsten Schiers
Gesendet: Freitag, 10. Juni 2011 16:56
An: ''Tian, Kevin''; ''xen-devel''
Betreff: AW: RE: RE: RE: [Xen-devel] No C-States any longer...
Some in-between notes, if someone is better in analyzing the code. There
is the following sequence In drivers/scpi/processor_idle.c:
result = acpi_processor_get_power_info_cst(pr);
if (result == -ENODEV)
result = acpi_processor_get_power_info_fadt(pr);
if (result)
return result;
acpi_processor_get_power_info_default(pr);
On a working Intel machine, it will go through it like this:
- acpi_processor_get_power_info_cst, which returns 0
- acpi_processor_get_power_info_default
- later acpi_processor_power_verify will find some c-states
On my non-working AMD machine, it will go through like this:
- acpi_processor_get_power_info_cst, which returns -ENODEV
- acpi_processor_get_power_info_fadt, which also return -ENODEV
- this result is returned
The returned result -ENODEV is cascaded up to the call in
xen_acpi_processor_power_init, but there nothing is checked or done.
I will now try to find the root cause (acpi_processor_get_power_info_cst
is to be checked next).
Carsten.
-----Ursprüngliche Nachricht-----
Von: Tian, Kevin [mailto:kevin.tian@intel.com]
Gesendet: Freitag, 10. Juni 2011 10:49
An: Carsten Schiers; xen-devel
Betreff: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Friday, June 10, 2011 3:09 AM
>
> Through some adding of printk I was able at least to verify that for
my> 3 core CPU AMD Athlon X3 400e
>
> - xen_px_notifier is called six times
> - Hypervisor is reporting XEN_PM_PX is called six times
> - Hypervisor is never reporting XEN_PM_CX to have been called
> - this is because xen_cx_notifier is never called.
> -> set_cx_pminfo is never called.
>
> What I will try to find out next is to check where xen_cx_notifier
> *should* be called. OS debugging is
> not realy my expertise, let''s see whether you first can give me a
hint
> or whether I am quicker to find it on my own.
>
the entry point in dom0 looks like:
xen_acpi_processor_start
xen_acpi_processor_power_init
processor_cntl_xen_notify
xen_ops.pm_ops
xen_cx_notifier
HYPERVISOR_dom0_op
Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-12 09:01 UTC
RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Saturday, June 11, 2011 5:26 PM > > I switched on ACPI_DEBUG but the result is not surprising: > > Jun 11 10:56:48 data kernel: [ 186.897468] nsutils-0461 > [ffff880002b1db00] [00] ns_build_internal_name: Returning > [ffff88000ed14988] (rel) "_CST" > Jun 11 10:56:48 data kernel: [ 186.897473] utmutex-0257 > [ffff880002b1db00] [00] ut_acquire_mutex : Thread ffff880002b1db00 > attempting to acquire Mutex [ACPI_MTX_Namespace] > Jun 11 10:56:48 data kernel: [ 186.897479] osl-0872 > [ffff880002b1db00] [00] os_wait_semaphore : Waiting for > semaphore[ffff88000fc2e1e0|1|65535] > Jun 11 10:56:48 data kernel: [ 186.897485] osl-0891 > [ffff880002b1db00] [00] os_wait_semaphore : Acquired > semaphore[ffff88000fc2e1e0|1|65535] utmutex-0265 [ffff880002b1db00] [00] > ut_acquire_mutex : Thread ffff880002b1db00 acquired Mutex > [ACPI_MTX_Namespace] > Jun 11 10:56:48 data kernel: [ 186.897496] nsaccess-0399 > [ffff880002b1db00] [00] ns_lookup : Searching relative to > prefix scope [C002] (ffff88000fc2e4a0) > Jun 11 10:56:48 data kernel: [ 186.897501] nsaccess-0511 > [ffff880002b1db00] [00] ns_lookup : Simple Pathname (1 > segment, Flags=2) > Jun 11 10:56:48 data kernel: [ 186.897506] nsdump-0087 > [ffff880002b1db00] [00] ns_print_pathname : [_CST] > Jun 11 10:56:48 data kernel: [ 186.897515] nssearch-0114 > [ffff880002b1db00] [00] ns_search_one_scope : Searching \_PR_.C002 > (ffff88000fc2e4a0) For [_CST] (Untyped) > Jun 11 10:56:48 data kernel: [ 186.897521] nssearch-0179 > [ffff880002b1db00] [00] ns_search_one_scope : Name [_CST] (Untyped) > not found in search in scope [C002] ffff88000fc2e4a0 first child > ffff88000fa54700 > Jun 11 10:56:48 data kernel: [ 186.897528] nssearch-0390 > [ffff880002b1db00] [00] ns_search_and_enter : _CST Not found in > ffff88000fc2e4a0 [Not adding] > Jun 11 10:56:48 data kernel: [ 186.897533] nsaccess-0572 > [ffff880002b1db00] [00] ns_lookup : Name [_CST] not found in > scope [C002] ffff88000fc2e4a0 > Jun 11 10:56:48 data kernel: [ 186.897539] nsutils-0876 > [ffff880002b1db00] [00] ns_get_node : _CST, AE_NOT_FOUND > Jun 11 10:56:48 data kernel: [ 186.897544] utmutex-0299 > [ffff880002b1db00] [00] ut_release_mutex : Thread ffff880002b1db00 > releasing Mutex [ACPI_MTX_Namespace] > Jun 11 10:56:48 data kernel: [ 186.897549] osl-0911 > [ffff880002b1db00] [00] os_signal_semaphore : Signaling > semaphore[ffff88000fc2e1e0|1] > Jun 11 10:56:48 data kernel: [ 186.897555] > acpi_processor_get_power_info_cst bad cst > Jun 11 10:56:48 data kernel: [ 186.897557] processor_idle-0363 > [ffff880002b1db00] [00] processor_get_power_in: No _CST, giving up > Jun 11 10:56:48 data kernel: [ 186.897562] > acpi_processor_get_power_info result=-19, -ENODEV=-19 > Jun 11 10:56:48 data kernel: [ 186.897563] > acpi_processor_get_power_info analyzes fadt > Jun 11 10:56:48 data kernel: [ 186.897565] > acpi_processor_get_power_info result=-19, -ENODEV=-19 > Jun 11 10:56:48 data kernel: [ 186.897567] > acpi_processor_get_power_info we have a result > Jun 11 10:56:48 data kernel: [ 186.897569] > xen_acpi_processor_get_power_info returns=-19 > Jun 11 10:56:48 data kernel: [ 186.897570] > xen_acpi_processor_power_init got power info > Jun 11 10:56:48 data kernel: [ 186.897572] > xen_acpi_processor_power_init not power flags > Jun 11 10:56:48 data kernel: [ 186.897574] scan-0568 > [ffff880002b1db00] [00] bus_driver_init : Driver successfully > bound to device > Jun 11 10:56:48 > > It doesn''t find _CST, as we did not in the extract of acpiextract. > Unfortunately, the old, working Xen 4.1.0/Linux 2.6.18 combo doesn''t > boot any longer, because > I upgraded to Debian Squeeze already and something doesn''t work with the > udev version. I will try to boot native Linux in order to verify 100% > that the tables > are there.yes, that''s interesting data to compare.> > If we already assume this, the cause should be in the way how pvops > Linux is mapping the tables into the system, shouldn''t it`Or the DSDT table may be corrupted by some undesired operation, however random corruption may lead to more errors than missing _CST here. Did you change BIOS setting recently? Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-13 13:21 UTC
AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
>>I will try to boot native Linux in order to verify 100% >> that the tables >> are there. > >yes, that''s interesting data to compare.I have booted with a Live Linux and dumped acpi tables. Those are 100% identical with those I received from Dom0. I will now start looking into acpi_processor_get_power_info_fadt And check, why it is returning -ENODEV. Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-13 20:27 UTC
AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
One step further: the problem is that pr->pblk is not set, thus acpi_processor_get_power_info_fadt fails. Knowing this, I found an error in the ACPI_DEBUG output that corresponds: [ 17.062739] processor_xen-0222 [00] xen_acpi_processor_get: Processor [-1:0] [ 17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No PBLK (NULL address) It does this for all processors. pr_id is always -1, pr->acpi_id counting up from 0 to 2. Any help is welcome, but I will analyze further... Carsten. -----Ursprüngliche Nachricht----- Von: Carsten Schiers Gesendet: Montag, 13. Juni 2011 15:22 An: ke.yu; kevin.tian Cc: xen-devel Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...>>I will try to boot native Linux in order to verify 100% >> that the tables >> are there. > >yes, that''s interesting data to compare.I have booted with a Live Linux and dumped acpi tables. Those are 100% identical with those I received from Dom0. I will now start looking into acpi_processor_get_power_info_fadt And check, why it is returning -ENODEV. Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-15 08:11 UTC
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Tuesday, June 14, 2011 4:27 AM > > One step further: the problem is that pr->pblk is not set, thus > acpi_processor_get_power_info_fadt fails. > Knowing this, I found an error in the ACPI_DEBUG output that > corresponds: > > [ 17.062739] processor_xen-0222 [00] xen_acpi_processor_get: Processor > [-1:0] > [ 17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No PBLK > (NULL address)this looks a bit strange. how about the native log?> > It does this for all processors. pr_id is always -1, pr->acpi_id > counting up from 0 to 2.what''s your dom0 vcpu number? and how about physical cpu?> > Any help is welcome, but I will analyze further...Current Dom0 depends on several Xen specific functions like xen_acpi_get_power_info you mentioned earlier, which is a copy from native acpi_get_power_info with xen specific tweaks added. there''s possibility that in your environment general ACPI code is changed which is not reflected in Xen specific versions. Thanks Kevin> > Carsten. > > -----Ursprüngliche Nachricht----- > Von: Carsten Schiers > Gesendet: Montag, 13. Juni 2011 15:22 > An: ke.yu; kevin.tian > Cc: xen-devel > Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer... > > >>I will try to boot native Linux in order to verify 100% > >> that the tables > >> are there. > > > >yes, that''s interesting data to compare. > > I have booted with a Live Linux and dumped acpi tables. Those are 100% > identical with those > I received from Dom0. I will now start looking into > acpi_processor_get_power_info_fadt And > check, why it is returning -ENODEV. > > Carsten. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-15 08:15 UTC
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Monday, June 13, 2011 9:22 PM > > >>I will try to boot native Linux in order to verify 100% > >> that the tables > >> are there. > > > >yes, that''s interesting data to compare. > > I have booted with a Live Linux and dumped acpi tables. Those are 100% > identical with those > I received from Dom0. I will now start looking into > acpi_processor_get_power_info_fadt And > check, why it is returning -ENODEV.Is your native linux with same version as dom0? It''s better to use a same version native kernel to make sure that this is not a generic ACPI bug. There tends to various issues regarding to ACPI power management time to time on different machines, which happens on native linux too. If you can confirm this point, then we may reduce the area down to xen specific acpi stubs. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jun-15 08:34 UTC
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote:> > From: Carsten Schiers [mailto:carsten@schiers.de] > > Sent: Tuesday, June 14, 2011 4:27 AM > > > > One step further: the problem is that pr->pblk is not set, thus > > acpi_processor_get_power_info_fadt fails. > > Knowing this, I found an error in the ACPI_DEBUG output that > > corresponds: > > > > [ 17.062739] processor_xen-0222 [00] xen_acpi_processor_get: Processor > > [-1:0] > > [ 17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No PBLK > > (NULL address) > > this looks a bit strange. how about the native log? > > > > > It does this for all processors. pr_id is always -1, pr->acpi_id > > counting up from 0 to 2. > > what''s your dom0 vcpu number? and how about physical cpu?Wasn''t there some oddity in the Xen ACPI PM support due to the disconnect between VCPU and PCPU? I thought it resulted in some CPU id or other being reported back as -1, in much this manner. There''s some tweaking of this stuff in e.g. xen_acpi_processor_get_power_info(). But equally xen_acpi_processor_get_info() has a bunch of cases for the != -1 case. Does the dom0_vcpus_pin hypervisor option workaround this sort of thing? This changeset refers to the -1 too: commit 68320323a51c2378aca433c76157d9e66104ff1e Author: Jiang, Yunhong <yunhong.jiang@intel.com> Date: Tue Sep 14 14:41:52 2010 -0700 xen/acpi: Add cpu hotplug support Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. Please notice that, even with this change, the acpi_processor->id is still always -1. This is because several workaround in PM side depends on acpi_processor->id == -1. As the CPU hotplug logic does not depends on acpi_processor->id, I''d still keep it no changes. But we need change the acpi_processor->id in the future. Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Ian.> > Any help is welcome, but I will analyze further... > > Current Dom0 depends on several Xen specific functions like xen_acpi_get_power_info > you mentioned earlier, which is a copy from native acpi_get_power_info with xen > specific tweaks added. there''s possibility that in your environment general ACPI code > is changed which is not reflected in Xen specific versions. > > Thanks > Kevin > > > > > Carsten. > > > > -----Ursprüngliche Nachricht----- > > Von: Carsten Schiers > > Gesendet: Montag, 13. Juni 2011 15:22 > > An: ke.yu; kevin.tian > > Cc: xen-devel > > Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer... > > > > >>I will try to boot native Linux in order to verify 100% > > >> that the tables > > >> are there. > > > > > >yes, that''s interesting data to compare. > > > > I have booted with a Live Linux and dumped acpi tables. Those are 100% > > identical with those > > I received from Dom0. I will now start looking into > > acpi_processor_get_power_info_fadt And > > check, why it is returning -ENODEV. > > > > Carsten. > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-15 08:39 UTC
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Wednesday, June 15, 2011 4:35 PM > > On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote: > > > From: Carsten Schiers [mailto:carsten@schiers.de] > > > Sent: Tuesday, June 14, 2011 4:27 AM > > > > > > One step further: the problem is that pr->pblk is not set, thus > > > acpi_processor_get_power_info_fadt fails. > > > Knowing this, I found an error in the ACPI_DEBUG output that > > > corresponds: > > > > > > [ 17.062739] processor_xen-0222 [00] xen_acpi_processor_get: > Processor > > > [-1:0] > > > [ 17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No PBLK > > > (NULL address) > > > > this looks a bit strange. how about the native log? > > > > > > > > It does this for all processors. pr_id is always -1, pr->acpi_id > > > counting up from 0 to 2. > > > > what's your dom0 vcpu number? and how about physical cpu? > > Wasn't there some oddity in the Xen ACPI PM support due to the > disconnect between VCPU and PCPU? I thought it resulted in some CPU id > or other being reported back as -1, in much this manner.yes, the existing tricky changes are mostly used to tackle this disconnection.> > There's some tweaking of this stuff in e.g. > xen_acpi_processor_get_power_info(). But equally > xen_acpi_processor_get_info() has a bunch of cases for the != -1 case. > > Does the dom0_vcpus_pin hypervisor option workaround this sort of thing?We don't want to add that limitation to have dom0 vcpu number same as physical cpu number to use PM features. But yes Carsten can try use same number to see whether it works for him. If it works, then there's other corner cases we didn't capture. But since this works on his Intel box, which I guess same configuration is used, I'd think it may come from some oddity in AMD box's ACPI table which is not well handled by either common ACPI code or Xen specific stubs. Thanks Kevin> > This changeset refers to the -1 too: > > commit 68320323a51c2378aca433c76157d9e66104ff1e > Author: Jiang, Yunhong <yunhong.jiang@intel.com> > Date: Tue Sep 14 14:41:52 2010 -0700 > > xen/acpi: Add cpu hotplug support > > Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. > Please notice that, even with this change, the acpi_processor->id is > still always -1. This is because several workaround in PM side depends > on acpi_processor->id == -1. As the CPU hotplug logic does not depends > on acpi_processor->id, I'd still keep it no changes. > > But we need change the acpi_processor->id in the future. > > Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com> > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > > Ian. > > > > Any help is welcome, but I will analyze further... > > > > Current Dom0 depends on several Xen specific functions like > xen_acpi_get_power_info > > you mentioned earlier, which is a copy from native acpi_get_power_info with > xen > > specific tweaks added. there's possibility that in your environment general > ACPI code > > is changed which is not reflected in Xen specific versions. > > > > Thanks > > Kevin > > > > > > > > Carsten. > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Carsten Schiers > > > Gesendet: Montag, 13. Juni 2011 15:22 > > > An: ke.yu; kevin.tian > > > Cc: xen-devel > > > Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer... > > > > > > >>I will try to boot native Linux in order to verify 100% > > > >> that the tables > > > >> are there. > > > > > > > >yes, that's interesting data to compare. > > > > > > I have booted with a Live Linux and dumped acpi tables. Those are 100% > > > identical with those > > > I received from Dom0. I will now start looking into > > > acpi_processor_get_power_info_fadt And > > > check, why it is returning -ENODEV. > > > > > > Carsten. > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-15 09:14 UTC
AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> Is your native linux with same version as dom0?Not in this case, sorry. I used a Knoppix Live Linux CD.> It''s better to use a same version native kernel to make sure that this is not > a generic ACPI bug.Check is scheduled ;o). Thanks, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel