Bug 12391

Summary: Processor does not go below C2 state until usb.autosuspend is enabled
Product: ACPI Reporter: Gergely Imreh (imrehg)
Component: Power-ProcessorAssignee: ykzhao (yakui.zhao)
Status: REJECTED INVALID    
Severity: normal CC: acpi-bugzilla, rjw, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.28 Subsystem:
Regression: --- Bisected commit-id:
Attachments: lsusb -v output
list of loaded modules in the 2.6.27.10 kernel
list of loaded modules in the 2.6.28 kernel
.config used to compile kernel for 2.6.28
Output from acpidump.
Output of /proc/acpi/processor/*/power for working and failing cases
dmesg log during boot-up up for 2.6.27.10 kernel (fail case)
dmesg log during boot-up up for 2.6.28 kernel

Description Gergely Imreh 2009-01-09 02:35:35 UTC
Latest working kernel version:
2.6.27.10

Earliest failing kernel version:
2.6.28

Distribution:
Self-compiled kernel (on Arch Linux)

Hardware Environment:
Asus EeePC 8G, with replaced wireless card and increased memory


Software Environment:
-

Problem Description:
In the 2.6.27.10 kernel right after boot, if the CPU was idle, it went down to the C3 state (according to PowerTop 1.11). Powertop recommends usb.autosuspend to be enabled, but that does not change the processor's state.
In the 2.6.28 kernel, after boot the processor is stuck in C2 state. Powertop recommends usb.autosuspend, then the processor goes down successfully to C3 state.

Steps to reproduce:
1) Boot with 2.6.27.10 kernel
2) Use powertop to see C-state statistics (~100% in C3)
3) Boot with 2.6.28 kernel
4) Use powertop to see C-state statistics (~100% in C2)
5) Enable usb.autosuspend from powertop (~100% in C3)
Comment 1 Gergely Imreh 2009-01-09 02:36:24 UTC
Created attachment 19728 [details]
lsusb -v output
Comment 2 Gergely Imreh 2009-01-09 02:37:12 UTC
Created attachment 19729 [details]
list of loaded modules in the 2.6.27.10 kernel
Comment 3 Gergely Imreh 2009-01-09 02:37:27 UTC
Created attachment 19730 [details]
list of loaded modules in the 2.6.28 kernel
Comment 4 Gergely Imreh 2009-01-09 02:38:57 UTC
Created attachment 19731 [details]
.config used to compile kernel for 2.6.28

.config used to compile 2.6.28 kernel. 
The .config for the 2.6.27.10 kernel is the same .config loaded up with make menuconfig, which replaces the unknown values with their defaults.
Comment 5 Andrew Morton 2009-01-09 02:52:08 UTC
marked as regression, reassigned to acpi.
Comment 6 Gergely Imreh 2009-01-09 02:57:53 UTC
> Steps to reproduce:
> 1) Boot with 2.6.27.10 kernel
> 2) Use powertop to see C-state statistics (~100% in C3)
> 3) Boot with 2.6.28 kernel
> 4) Use powertop to see C-state statistics (~100% in C2)
> 5) Enable usb.autosuspend from powertop (~100% in C3)

As I checked once again, in addition to the usb.autosuspend, I have to kill the hald-addon-storage as well to be ~100% in C3 when idle.
If only kill hald-addon-storage, the CPU stays in C2; if only do usb.autosuspend it is 1/3 time in C2, 2/3 time in C3.
Comment 7 ykzhao 2009-01-11 21:22:26 UTC
Hi, Gergely
    Will you please double check whether the usb.autosuspend is enabled on the 2.6.27.10 kernel?
    Will you please also attach the output of acpidump?
    Thanks.
Comment 8 Len Brown 2009-01-12 19:17:22 UTC
for both the working and failing cases,
please attach the output of
"cat /proc/acpi/processor/*/power"

of particular interest in this file is the "bug master activity line",
which tells us not to enter C3 due to activity...
Comment 9 Gergely Imreh 2009-01-13 21:11:43 UTC
Created attachment 19779 [details]
Output from acpidump.
Comment 10 Gergely Imreh 2009-01-13 21:12:31 UTC
Created attachment 19780 [details]
Output of  /proc/acpi/processor/*/power for working and failing cases
Comment 11 Gergely Imreh 2009-01-13 21:21:39 UTC
(In reply to comment #7)
> Hi, Gergely
>     Will you please double check whether the usb.autosuspend is enabled on
>     the
> 2.6.27.10 kernel?
>     Will you please also attach the output of acpidump?
>     Thanks.
> 

On system start usb.autosuspend is not enabled in either 2.6.27.10 or 2.6.28. 

One strange thig is, though, checking /proc/acpi/processor/*/power, that on system start in case of 2.6.27.10 it reports the CPU to be in C2 ~100% while powertop says C3. In case of 2.6.28, both of them say the CPU is in C2. 
So to me it seems, based on /proc/acpi/processor/*/power, both kernels should behave similarly, that is not going to C3 unless there's usb.autosuspend enabled.
I tried powertop 1.10 and 1.11 (svn), both had the same behaviour (as in differing from /proc).

Actually: /proc/acpi/processor/*/power does not seem to contain too much information (well, at least not for me), do I have to turn on some other kernel parameters to get more useful statistics? Or this was what you were looking for?

Cheers,
    Greg
Comment 12 ykzhao 2009-01-15 23:04:24 UTC
Hi, Gergely
    From the log of /proc/acpi/processor/*/power we know that the most time will be hold by C2 state on the kernel of 2.6.27.10 if usb.autosuspend is disabling. But powertop reports that C3 is almost 100%.
    Will you please double check it again?
    Please also attach the output of demsg on the working/failing kernel.
    Thanks.
Comment 13 Gergely Imreh 2009-01-21 00:46:57 UTC
Hi,

 Sorry about the delay. I checked it again, and for both cases the autosuspend was the same, and things worked as I described them before. Here's the list of devices, at start, with default autosuspend values read from their info in /sys:

Internal card reader
  1-5 -> 0cf2:6225 -> disabled
eMPIA Technology, Inc. EeePC 701 integrated Webcam
  1-8 -> eb1a:2761 -> disbled
Linux Foundation 2.0 root hub
  usb1 -> 1d6b:0002 -> enabled
Linux Foundation 1.1 root hub
  usb2 -> 1d6b:0001 -> enabled
  usb3 -> 1d6b:0001 -> enabled
  usb4 -> 1d6b:0001 -> enabled
  usb5 -> 1d6b:0001 -> enabled

  I attach the dmesg as well.
  What could make PowerTOP report wrong value, is there more than one place to get the information?
Comment 14 Gergely Imreh 2009-01-21 00:48:38 UTC
Created attachment 19916 [details]
dmesg log during boot-up up for 2.6.27.10 kernel (fail case)
Comment 15 Gergely Imreh 2009-01-21 00:49:09 UTC
Created attachment 19917 [details]
dmesg log during boot-up up for 2.6.28 kernel
Comment 16 Zhang Rui 2009-02-25 17:46:57 UTC
this(no C3 without usb.autosuspend) sounds reasonable, as there are a lot of wakeup event is usb is running all the time.

Yakui, is this a real problem that we should get a fix for?
Comment 17 Shaohua 2009-03-03 22:58:22 UTC
this isn't a bug. With the USB enabled, C3 can't be entered.