Created attachment 21071 [details] lsusb -v Latest working kernel version: 2.6.26-13 Earliest failing kernel version: 2.6.28 Distribution: Debian Sid Hardware Environment: IBM Thinkpad T41 Pentium M Problem Description: In 2.6.28(29) kernel, when I plug in usb logitech mouse, regression in uhci (I assume it's usb uhci driver) forces processor to operate in C2 state (reported by powertop 1.11). When I plug it off, everything back to normal - 100% C3 in idle. In 2.6.26 kernel processor normally goes down to C3 when mouse is plugged in. I think this problem was already reported in this bug [1] and closed without proper investigation. Arjan van de Ven stated that "When USB is used C3 cannot be entered" argument isn't correct [2]. I'll provide any additional debug data if needed. [1] http://bugzilla.kernel.org/show_bug.cgi?id=12391 [2] http://www.bughost.org/pipermail/power/2009-March/001617.html
(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. On Tue, 21 Apr 2009 19:53:13 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13145 > > Summary: Processor does not go below C2 if mouse (uhci) is > plugged in. > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.29 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: USB > AssignedTo: greg@kroah.com > ReportedBy: daniel.smoczyk@gmail.com > Regression: Yes > > > Created an attachment (id=21071) > --> (http://bugzilla.kernel.org/attachment.cgi?id=21071) > lsusb -v > > Latest working kernel version: > 2.6.26-13 > > Earliest failing kernel version: > 2.6.28 > > Distribution: > Debian Sid > > Hardware Environment: > IBM Thinkpad T41 Pentium M > > Problem Description: > In 2.6.28(29) kernel, when I plug in usb logitech mouse, regression in uhci > (I > assume it's usb uhci driver) forces processor to operate in C2 state > (reported > by powertop 1.11). When I plug it off, everything back to normal - 100% C3 in > idle. In 2.6.26 kernel processor normally goes down to C3 when mouse is > plugged > in. > > I think this problem was already reported in this bug [1] and closed without > proper investigation. Arjan van de Ven stated that "When USB is used C3 > cannot > be entered" argument isn't correct [2]. > > I'll provide any additional debug data if needed. > > [1] http://bugzilla.kernel.org/show_bug.cgi?id=12391 > [2] http://www.bughost.org/pipermail/power/2009-March/001617.html >
On Tue, 21 Apr 2009 14:27:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > (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? > 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)
Reply-To: oliver@neukum.org Am Dienstag 21 April 2009 23:27:51 schrieb Andrew Morton: > (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? Not going into C3 without autosuspend is really expected. > > [1] http://bugzilla.kernel.org/show_bug.cgi?id=12391 > > [2] http://www.bughost.org/pipermail/power/2009-March/001617.html Going by http://bugzilla.kernel.org/attachment.cgi?id=19780 is the CPU really in C3 under 2.6.26 without autosuspend? Regards Oliver
On Wed, 22 Apr 2009 00:22:14 +0200 Oliver Neukum <oliver@neukum.org> wrote: > Am Dienstag 21 April 2009 23:27:51 schrieb Andrew Morton: > > (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? > > Not going into C3 without autosuspend is really expected. this is not correct; if the CPU supports "C2-popup", going to C3 is expected.
Reply-To: oliver@neukum.org Am Mittwoch 22 April 2009 01:49:10 schrieb Arjan van de Ven: > On Wed, 22 Apr 2009 00:22:14 +0200 > > Oliver Neukum <oliver@neukum.org> wrote: > > Am Dienstag 21 April 2009 23:27:51 schrieb Andrew Morton: > > > (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? > > > > Not going into C3 without autosuspend is really expected. > > this is not correct; if the CPU supports "C2-popup", going to C3 is > expected. Yes, that's possible. Does the system in question? Regards Oliver
On Wed, Apr 22, 2009 at 04:48:30PM +0800, Oliver Neukum wrote: > Am Mittwoch 22 April 2009 01:49:10 schrieb Arjan van de Ven: > > On Wed, 22 Apr 2009 00:22:14 +0200 > > > > Oliver Neukum <oliver@neukum.org> wrote: > > > Am Dienstag 21 April 2009 23:27:51 schrieb Andrew Morton: > > > > (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? > > > > > > Not going into C3 without autosuspend is really expected. > > > > this is not correct; if the CPU supports "C2-popup", going to C3 is > > expected. > > Yes, that's possible. Does the system in question? IIRC, C2-popup is supported since core architecture. The system (a T41) is unlikely support this. Thanks, Shaohua
On Tue, 21 Apr 2009, Andrew Morton wrote: > It looks like we need to revisit this - 2.6.26 worked OK, so why can't > 2.6.28? 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
On Wed, Apr 22, 2009 at 4:51 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > In fact the bug report says that 2.6.27 worked okay. Not true, didn't tested 2.6.27 - there wasn't such one in debian repos. > 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. 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
On Wed, 22 Apr 2009, Daniel Smoczyk wrote: > On Wed, Apr 22, 2009 at 4:51 PM, Alan Stern <stern@rowland.harvard.edu> > wrote: > > > In fact the bug report says that 2.6.27 worked okay. > > Not true, didn't tested 2.6.27 - there wasn't such one in debian repos. I'm going by the data in http://bugzilla.kernel.org/attachment.cgi?id=19780 which is attached to bug #12391. > > 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. > > 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") 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. > This situation is very similar to using usb memory stick non-stop, > when watching move for eg. then processor also never goes below C2. 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
Reply-To: oliver@neukum.org Am Mittwoch 22 April 2009 16:51:38 schrieb Alan Stern: > On Tue, 21 Apr 2009, Andrew Morton wrote: > > It looks like we need to revisit this - 2.6.26 worked OK, so why can't > > 2.6.28? > > In fact the bug report says that 2.6.27 worked okay. 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
Reply-To: lenb@kernel.org > IIRC, C2-popup is supported since core architecture. The system (a T41) > is unlikely support this. 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
Reply-To: lenb@kernel.org 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
2.6.26 also detects the Bus Mastering activity and goes into C2 state instead of C3. But, it reports the time as "C3 time". Thats the reason powertop shows time spent in C3, even though in reality CPU is in C2. This patch "cpuidle: update the last_state acpi cpuidle reflecting actual state entered" fixes the C-state reporting bug and now we correctly report the time being spent in C2 and not C3. So, this is not a bug. This is rather a bug fix for wrong C-state reporting in powertop in earlier kernels.
Reply-To: lenb@kernel.org > That bug was fixed by commit fc2e4009300088813c3be2de80b01ddc2399999e > "cpuidle: update the last_state acpi cpuidle reflecting actual state entered" > > which shipped in 2.6.27 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