[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



It then implicates the possibility of a general bug in ACPI on this special AMD box, which then gets fixed in later kernel (so why Konrad’s 2.6.39 tree works). It’s not Xen/Dom0 specific.

 

I suggest you move to Konrad’s tree when it’s ready.

 

Thanks

Kevin

 

From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
Sent: Friday, June 17, 2011 3:34 AM
To: Tian, Kevin
Cc: Ian.Campbell; Yu, Ke; mark.langsdorf; xen-devel
Subject: AW: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...

 

>> So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively,

>> without Xen, and check

>> what acpi.debug and my printks are reporting?

>

>yes

 

Booting the very kernel on bare hardware will not change the way things are running,

despite one small change: the CPUs are registered as "cooling devices" ?!?

 

[    3.568766] ACPI: Power Button [PWRF]

[    3.734140] acpi_processor_get_power_info called

[    3.734200] acpi_processor_get_power_info zeroes all c-states

[    3.734260] acpi_processor_get_power_info analyzes cst

[    3.734319] acpi_processor_get_power_info_cst called

[    3.734377] acpi_processor_get_power_info_cst conted

[    3.734436] acpi_processor_get_power_info_cst bad cst

[    3.734495] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.734556] acpi_processor_get_power_info analyzes fadt

[    3.734614] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.734675] acpi_processor_get_power_info we have a result

[    3.734774] processor LNXCPU:00: registered as cooling_device0

[    3.734855] acpi_processor_get_power_info called

[    3.734912] acpi_processor_get_power_info zeroes all c-states

[    3.734973] acpi_processor_get_power_info analyzes cst

[    3.735031] acpi_processor_get_power_info_cst called

[    3.735089] acpi_processor_get_power_info_cst conted

[    3.735147] acpi_processor_get_power_info_cst bad cst

[    3.735206] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735267] acpi_processor_get_power_info analyzes fadt

[    3.735325] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735386] acpi_processor_get_power_info we have a result

[    3.735463] processor LNXCPU:01: registered as cooling_device1

[    3.735542] acpi_processor_get_power_info called

[    3.735599] acpi_processor_get_power_info zeroes all c-states

[    3.735659] acpi_processor_get_power_info analyzes cst

[    3.735717] acpi_processor_get_power_info_cst called

[    3.735775] acpi_processor_get_power_info_cst conted

[    3.735834] acpi_processor_get_power_info_cst bad cst

[    3.735892] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.735954] acpi_processor_get_power_info analyzes fadt

[    3.736013] acpi_processor_get_power_info result=-19, -ENODEV=-19

[    3.736074] acpi_processor_get_power_info we have a result

[    3.736305] processor LNXCPU:02: registered as cooling_device2

 

I did a cat on /proc/acpi/processor/cpu0 files:

 

info

----

processor id:            0

acpi id:                 0

bus mastering control:   yes

power management:        no

throttling control:      no

limit interface:         no

 

limit:

<not supported>

 

power:

------

active state:            C0

max_cstate:              C8

maximum allowed latency: 2000000000 usec

states:

 

throttling:

-----------

<not supported>

 

Carsten.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.