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

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

> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> Sent: Sunday, June 12, 2011 6:24 PM
> 
> There are some information in FACP (attached), there is no FADT.

FADT is plain text table, not encoded with AML language. It should be always 
there. :-)

Thanks
Kevin

> 
> In order to test native Linux, I need some more days. Family & Barbecue
> have higher Prio ;o).
> 
> Carsten.
> 
> -----Ursprüngliche Nachricht-----
> Von: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Gesendet: Sonntag, 12. Juni 2011 10:57
> An: Carsten Schiers; xen-devel
> Betreff: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> 
> > From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> > Sent: Friday, June 10, 2011 10:56 PM
> >
> > 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
> 
> this is expected sequence
> 
> >
> > 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
> 
> though CST is optional, it's weird that even FADT doesn't contain valid
> Cx
> information. Could you compare with your working pvops dom0 version or
> compare with generic linux to see any difference? This parse logic
> should
> be generic for both Linux and Xen.
> 
> >
> > 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).
> 
> Anyway, you seems close to the root cause...
> Thanks
> Kevin
> 
> 


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