AW: RE: RE: RE: RE: [Xen-devel] No C-States any longer...

["Carsten Schiers" <carsten@xxxxxxxxxx>]

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@xxxxxxxxx] 
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@xxxxxxxxxx] 
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@xxxxxxxxx]
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@xxxxxxxxxx]
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel