On Fri, Mar 28, 2008 at 12:44:26PM -0700, David Brownell wrote:
quoted text
> On Friday 28 March 2008, Pallipadi, Venkatesh wrote:
> 
> > >> > I noticed this with 2.6.25-rc2 (if not before), and the problem
> > >> > is still there with 2.6.25-rc6-git (as of this AM).
> > >
> > >A 2.6.24 kernel I still had stashed away didn't act odd; the
> > >problem joined us before 2.6.25-rc1 was tagged.
> > >
> > 
> > There was a fix that went in recently (one or two days back) that should
> > have fixed this.
> > Commit 8e92b6605da989
> > 
> > Can you check with latest git to see whether this is still a problem?
> 
> The problem is still there in GIT as of this morning, which
> includes 8e92b6605da989 ...
> 
> Comments on why bc71bec91f9875ef825d12104acf3bf4ca215fa4 seems
> to be causing this?  I think it's just bad reports getting to
> userspace, rather than an actual 120K wakeups/second.  (The
> report is of course not always 120K, but it's usually in that
> range.)

No. If powertop is reporting that many wakeups, there should be that many as
powertop gets wakeups from usage in /proc/acpi/processor/CPU*/power

Can you send me the output of
# grep . /sys/devices/system/cpu/cpu*/cpuidle/*/*
with upstream kernel.

Below is a test patch which should effectively revert commit bc71bec91f987
Can you check with this patch on latest git and see whether things come back
to normal.

Also, it will help if you can send the output of acpidump from this system.

Thanks,
Venki


---
 drivers/acpi/processor_idle.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Index: linux-2.6/drivers/acpi/processor_idle.c
===================================================================
--- linux-2.6.orig/drivers/acpi/processor_idle.c	2008-03-28 12:07:23.000000000 -0700
+++ linux-2.6/drivers/acpi/processor_idle.c	2008-03-28 13:17:31.000000000 -0700
@@ -943,16 +943,15 @@ static int acpi_processor_get_power_info
 			if (acpi_processor_ffh_cstate_probe
 					(pr->id, &cx, reg) == 0) {
 				cx.entry_method = ACPI_CSTATE_FFH;
-			} else if (cx.type == ACPI_STATE_C1) {
+			} else if (cx.type != ACPI_STATE_C1) {
 				/*
 				 * C1 is a special case where FIXED_HARDWARE
 				 * can be handled in non-MWAIT way as well.
 				 * In that case, save this _CST entry info.
+				 * That is, we retain space_id of SYSTEM_IO for
+				 * halt based C1.
 				 * Otherwise, ignore this info and continue.
 				 */
-				cx.entry_method = ACPI_CSTATE_HALT;
-				snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI HLT");
-			} else {
 				continue;
 			}
 		} else {
@@ -1398,8 +1397,6 @@ static inline void acpi_idle_do_entry(st
 	if (cx->entry_method == ACPI_CSTATE_FFH) {
 		/* Call into architectural FFH based C-state */
 		acpi_processor_ffh_cstate_enter(cx);
-	} else if (cx->entry_method == ACPI_CSTATE_HALT) {
-		acpi_safe_halt();
 	} else {
 		int unused;
 		/* IO port based C-state */
@@ -1443,7 +1440,7 @@ static int acpi_idle_enter_c1(struct cpu
 		acpi_idle_update_bm_rld(pr, cx);
 
 	t1 = inl(acpi_gbl_FADT.xpm_timer_block.address);
-	acpi_idle_do_entry(cx);
+	acpi_safe_halt();
 	t2 = inl(acpi_gbl_FADT.xpm_timer_block.address);
 
 	local_irq_enable();
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/