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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel