Bug 12391

Created attachment 19728 [details]
lsusb -v output

Created attachment 19729 [details]
list of loaded modules in the 2.6.27.10 kernel

Created attachment 19730 [details]
list of loaded modules in the 2.6.28 kernel

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.

marked as regression, reassigned to acpi.

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

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.

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

Created attachment 19779 [details]
Output from acpidump.

Created attachment 19780 [details]
Output of  /proc/acpi/processor/*/power for working and failing cases

(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

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.

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?

Created attachment 19916 [details]
dmesg log during boot-up up for 2.6.27.10 kernel (fail case)

Created attachment 19917 [details]
dmesg log during boot-up up for 2.6.28 kernel

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?

this isn't a bug. With the USB enabled, C3 can't be entered.