On Fri, Mar 28, 2008 at 03:09:22PM -0700, David Brownell wrote: > On Friday 28 March 2008, Pallipadi, Venkatesh wrote: > > You should have a dmesg line which looks like > > ACPI: CPU0 (power states: C1[C1] C2[C2] > > Do you see C2 in such line? > > Yes: > > ACPI: CPU0 (power states: C1[C1] C2[C2]) David, I think I figured out the bug... Can you try the below patch and confirm that it works (over upstream - ignore the earlier revert patch I sent to you). Thanks, Venki ---- Patch to fix huge number of wakeups reported due to recent changes in processor_idle.c. The problem was that the entry_method determination was broken due to one of the recent commits (bc71bec91f987) causing C1 entry to not to go to halt. This should also fix the hang reported here. http://bugzilla.kernel.org/show_bug.cgi?id=10093 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx> --- drivers/acpi/processor_idle.c | 4 ++++ 1 file changed, 4 insertions(+) Index: linux-2.6/drivers/acpi/processor_idle.c =================================================================== --- linux-2.6.orig/drivers/acpi/processor_idle.c 2008-03-28 15:31:13.000000000 -0700 +++ linux-2.6/drivers/acpi/processor_idle.c 2008-03-28 15:40:50.000000000 -0700 @@ -848,6 +848,7 @@ static int acpi_processor_get_power_info /* all processors need to support C1 */ pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1; pr->power.states[ACPI_STATE_C1].valid = 1; + pr->power.states[ACPI_STATE_C1].entry_method = ACPI_CSTATE_HALT; } /* the C0 state only exists as a filler in our array */ pr->power.states[ACPI_STATE_C0].valid = 1; @@ -960,6 +961,9 @@ static int acpi_processor_get_power_info cx.address); } + if (cx.type == ACPI_STATE_C1) { + cx.valid = 1; + } obj = &(element->package.elements[2]); if (obj->type != ACPI_TYPE_INTEGER) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
