* AW: RE: RE: RE: RE: RE: No C-States any longer...(it's not over!)
@ 2011-06-27 11:12 Carsten Schiers
2011-07-01 7:29 ` Tian, Kevin
0 siblings, 1 reply; 2+ messages in thread
From: Carsten Schiers @ 2011-06-27 11:12 UTC (permalink / raw)
To: Tian, Kevin, mark.langsdorf, xen-devel
Cc: Ian Campbell, Yu, Ke, Konrad Rzeszutek Wilk
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* RE: RE: RE: RE: RE: RE: No C-States any longer...(it's not over!)
2011-06-27 11:12 AW: RE: RE: RE: RE: RE: No C-States any longer...(it's not over!) Carsten Schiers
@ 2011-07-01 7:29 ` Tian, Kevin
0 siblings, 0 replies; 2+ messages in thread
From: Tian, Kevin @ 2011-07-01 7:29 UTC (permalink / raw)
To: Carsten Schiers, mark.langsdorf, xen-devel
Cc: Ian Campbell, Yu, Ke, Konrad Rzeszutek Wilk
> 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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-07-01 7:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-27 11:12 AW: RE: RE: RE: RE: RE: No C-States any longer...(it's not over!) Carsten Schiers
2011-07-01 7:29 ` Tian, Kevin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.