Bug 13145

(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 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