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
|
Home