New: Processor does not go below C2 if mouse (uhci) is plugged in.

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

It looks like we need to revisit this - 2.6.26 worked OK, so why can't 2.6.28?

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

2.6.28 ought to be able to work;

the one caveat is that powertop is reporting more accurate data in newer kernels (the newer kernels expose more details specifically for powertop) so it needs to be investigated to make sure this is not just some cosmetic issue.

(note that C3 might not be the right idea per se with such USB device in, but that is a different story)

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Am Dienstag 21 April 2009 23:27:51 schrieb Andrew Morton:

Not going into C3 without autosuspend is really expected.

Going by http://bugzilla.kernel.org/attachment.cgi?id=19780
is the CPU really in C3 under 2.6.26 without autosuspend?

Regards
Oliver

this is not correct; if the CPU supports "C2-popup", going to C3 is expected.

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Am Mittwoch 22 April 2009 01:49:10 schrieb Arjan van de Ven:

Yes, that's possible. Does the system in question?

Regards
Oliver

IIRC, C2-popup is supported since core architecture. The system (a T41) is unlikely support this.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

The T41 is an ICH4M, Pentium M system.
C2 popup was not supported until ICH6M.

Thus, when USB is active, this system should detect bus master activity (as displayed in /proc/acpi/processor/CPU/power) and should not enter C3 when such activity is (recently) present.

Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

In fact the bug report says that 2.6.27 worked okay.

However the changes to uhci-hcd between 2.6.27 and 2.6.28 are quite minimal. I can't see how any of them could have had this effect. It must be due to a change somewhere else in the kernel.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Not true, didn't tested 2.6.27 - there wasn't such one in debian repos.

Could You please check 26 <-> 27? In my opinion uhci-hcd was able to autosuspend while mouse wasn't used in 2.6.26 and it isn't able to do autosuspend now ( C3 works ok after "rmmod uhci-hcd")
This situation is very similar to using usb memory stick non-stop, when watching move for eg. then processor also never goes below C2.

Daniel Smoczyk
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I'm going by the data in

	http://bugzilla.kernel.org/attachment.cgi?id=19780

which is attached to bug #12391.

There was essentially no change to uhci-hcd between 2.6.26 and 2.6.27 (a static array definition got an added "const", that's all).

uhci-hcd has been able to autosuspend all along, provided no active devices (like a mouse) are attached. If you unplug the mouse and any other USB devices attached to the UHCI controller under 2.6.28, it should autosuspend.

But that's not what you were concerned about. Your original bug description said that the CPU wasn't going into C3 when the mouse _was_ attached.

Whenever a USB device is attached and not suspended, the host controller has to do DMA. Older processors are not able to enter C3 while DMA is active. So it would be good to verify whether your CPU is actually capable of doing it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Am Mittwoch 22 April 2009 16:51:38 schrieb Alan Stern:

We don't know that. It is possible that USB always worked as expected but ACPI's reporting of C states was broken and later fixed.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

This is not a re-gression, it is a pro-gression:-)

In the CONFIG_CPU_IDLE=y case, there was a bug where we
would enter C3 even in the presence of bus master activity.
That bug was fixed by commit fc2e4009300088813c3be2de80b01ddc2399999e "cpuidle: update the last_state acpi cpuidle reflecting actual state entered"

which shipped in 2.6.27

I've reproduced this issue on my t41, and when i revert the the patch above from 2.6.27, we erroneously attempt to enter C3
in the face of bus master activity, just like we did in 2.6.25 and 2.6.26.

Note that the CONFIG_CPU_IDLE=n case never had this bug, so you'd not see C3 with USB in that case even in older kernels.

Note also that /proc/acpi/processor/CPU/power does not display any bus master activity for the CONFIG_CPU_IDLE=y case, even when such activity is present. Now that CONFIG_CPU_IDLE=y for ACPI always, I think we should simply delete that misleading field.

thanks,
Len Brown, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

From: Len Brown <[email protected]>

The legacy ACPI idle handler was deleted from 2.6.29 leaving the CPU_IDLE idle handler, which never sets bm_activity.

So delete this unused field -- it is mis-leading to have it print all zeros when, in fact, there may bus master activity occurring -- just that we don't track its history any more.

This patch could break something that parses /proc/acpi/processor/*/power, since it deletes this line from that file:

bus master activity: 00000000

---
 drivers/acpi/processor_idle.c |    4 +---
 include/acpi/processor.h      |    1 -
 2 files changed, 1 insertions(+), 4 deletions(-)

index 9d1f01e..eed3b45 100644
@@ -662,11 +662,9 @@ static int acpi_processor_power_seq_show(struct seq_file *seq, void *offset)
 
 	seq_printf(seq, "active state:            C%zd\n"
 		   "max_cstate:              C%d\n"
-		   "bus master activity:     %08x\n"
 		   "maximum allowed latency: %d usec\n",
 		   pr->power.state ? pr->power.state - pr->power.states : 0,
-		   max_cstate, (unsigned)pr->power.bm_activity,
-		   pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY));
+		   max_cstate, pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY));
 
 	seq_puts(seq, "states:\n");
 

index b09c4fd..4927c06 100644
@@ -84,7 +84,6 @@ struct acpi_processor_power {
 	struct acpi_processor_cx *state;
 	unsigned long bm_check_timestamp;
 	u32 default_state;
-	u32 bm_activity;
 	int count;
 	struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
 	int timer_broadcast_on_state;

1.6.3.rc1.34.g0be9b


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Venki pointed out that fc2e4009300 shipped in 2.6.27.15. It was backported from addbad46ed0906cd584784423b9d0babc7476446 which shipped in 2.6.28

-Len Brown, Intel Open Source Technology Center