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