[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |