Xen devel - Jun 2011 - AW: RE: RE: RE: RE: RE: No C-States any longer...(it''s not over!)

I thought by buying a new mainboard, I could solve the issue. It is not the
case.
>> >In your case there''s no _CST found, and then no PBLK
found.
>...
>w/o PBLK, FADT info is incomplete to construct a full Cstate information.
The new mainboard now implements a PBLK for the first CPU in FADT, but latencies
for C2/C3
are > 100/1000, which is the semantic to disable it (I read). 

But no change in xenpm output, there are still no C-States. 

I think acpi_processor_get_power_info_default is called too late. In old,
working 2.6.18 code,
a similar function acpi_processor_get_power_info_default_c1 is called as very
first function in
acpi_processor_get_power_info, to setup C1 which is mandatory for all CPUs.

Some other thoughts where I see the code needs changes:

  - even if spec says that either PBLK or _CST should implement, C1 should be
set up (solves issue with mainboard 1)
  - when C2/C3 are above limits (100/1000), C1 still should be set up (solves
issue with mainboard 2)
  - Spec allows PBLK for one CPU only (definition as of mainboard 2, I
don''t think code is respecting this case).

BTW:

  - I have C1E support in CPU and BIOS, but see no difference in DSDT and FADT
when on/off in BIOS
  - Just curious: how many C-States should AMD X3 400e normally support? Why is
my BIOS switching off C2/C3?

Carsten.

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

> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Monday, June 27, 2011 7:13 PM
> 
> I thought by buying a new mainboard, I could solve the issue. It is not the
case.
> 
> >> >In your case there''s no _CST found, and then no PBLK
found.
> >...
> >w/o PBLK, FADT info is incomplete to construct a full Cstate
information.
> 
> The new mainboard now implements a PBLK for the first CPU in FADT, but
> latencies for C2/C3
> are > 100/1000, which is the semantic to disable it (I read).
> 
> But no change in xenpm output, there are still no C-States.
> 
> I think acpi_processor_get_power_info_default is called too late. In old,
> working 2.6.18 code,
> a similar function acpi_processor_get_power_info_default_c1 is called as
very
> first function in
> acpi_processor_get_power_info, to setup C1 which is mandatory for all CPUs.
this is the generic Linux ACPI logic, so you may report to Linux upstream for
their
opinion.
> 
> Some other thoughts where I see the code needs changes:
> 
>   - even if spec says that either PBLK or _CST should implement, C1 should
be
> set up (solves issue with mainboard 1)
>   - when C2/C3 are above limits (100/1000), C1 still should be set up
(solves
> issue with mainboard 2)
yes, I agree that C1 should be always present regardless of platform difference,
as long as cpuidle is enabled in Xen. I''ll try to work out a patch and
CC you when
it''s ready.

Thanks
Kevin

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