Bug 15675

Summary: Starting 2.6.32, C2 is used and results in 40000 wake/sec -- Lenovo 3000 N200
Product: ACPI Reporter: Wojo (wojo.spam)
Component: Power-ProcessorAssignee: acpi_power-processor
Status: REJECTED INSUFFICIENT_DATA    
Severity: high CC: lenb, mie.iscrizioni, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: dmidecode on 2.6.31.6
lspci on 2.6.31.6
/sys/firmware/acpi/interrupts/* on 2.6.31.6
powertop -d on ac on 2.6.31.6
powertop -d on battery on 2.6.31.6
/sys/firmware/acpi/interrupts/* on 2.6.32.10
powertop -d on ac on 2.6.32.10
powertop -d on battery on 2.6.32.10
lspci on 2.6.32.10
dmidecode on 2.6.32.10
powertop -d on ac on 2.6.34-rc3
powertop -d on ac on 2.6.34-rc3 with idle=halt
powertop -d on battery on 2.6.34-rc3
powertop -d on battery on 2.6.34-rc3 with idle=halt
/sys/firmware/acpi/interrupts/* on 2.6.34-rc3
/sys/firmware/acpi/interrupts/* on 2.6.34-rc3 with idle=halt
Copy of files from /sys/firmware/acpi/tables/dynamic/* (2.6.32.10, high number of wakeups)
dmesg -s64000 on 2.6.32.10 (high number of wakeups)
acpidump on 2.6.32.10 (high number of wakeups)
lsmod on 2.6.32.10 after booting without netowrking
dmesg -s64000 on 2.6.32.10 with acpi_osi=Linux and processor.max_cstate=1

Description Wojo 2010-04-01 23:13:42 UTC
Hello everyone.

I would like to report a bug related and close to this one:
https://bugzilla.kernel.org/show_bug.cgi?id=15377
Situation is almost the same, very high number of wakeups from idle per second. 

Computer is: Lenovo 3000 N200 with Intel Pentium Dual Core T2370 @1.73GHz.
Distribution is: Arch Linux x86_64

It was already discussed in bug #15377 and over here: http://bugs.archlinux.org/task/17771. 

It seems serious for me, makes my mobile work on laptop impossible due to very curt working time on battery with such number of wakeups and power consumption, from 3 hours to about 40 minutes.

I'm attaching few outputs in a minute, acquaint yourself with them, please.

The thing is wakeups are high just after modprobing "processor" module, here's some output from modprobing it:

ACPI: SSDT 000000003f6d94fb 00238 (v01 PmRef Cpu0Ist 000003000 INTL 20050624)
ACPI: SSDT 000000003f6d8e8c 005EA (v01 PmRef Cpu0Cst 000003001 INTL 20050624)
Marking TSC unstable due to TSC halts in idle
processor LNXCPU:00: registered as cooling_device0
ACPI: SSDT 000000003f6d9733 000C8(v01 PmRef Cpu1Ist 000003000 INTL 20050624)
ACPI: SSDT 00000000376d9476 00085 (v01 PmRef Cpu1Cst 000003000 INTL 20050624)
Swtiching to clocksource hpet
processor LNXCPU:01: registered as cooling_device1


I will also try with 2.6.34-rc1 and idle=halt flag tomorrow.

Thanks for any contribution in this case in advance,
Wojciech Ploskonka
Comment 1 Wojo 2010-04-01 23:16:04 UTC
Created attachment 25805 [details]
dmidecode on 2.6.31.6
Comment 2 Wojo 2010-04-01 23:16:43 UTC
Created attachment 25806 [details]
lspci on 2.6.31.6
Comment 3 Wojo 2010-04-01 23:19:00 UTC
Created attachment 25807 [details]
/sys/firmware/acpi/interrupts/* on 2.6.31.6
Comment 4 Wojo 2010-04-01 23:19:46 UTC
Created attachment 25808 [details]
powertop -d on ac on 2.6.31.6
Comment 5 Wojo 2010-04-01 23:20:35 UTC
Created attachment 25809 [details]
powertop -d on battery on 2.6.31.6
Comment 6 Wojo 2010-04-01 23:21:11 UTC
Created attachment 25810 [details]
/sys/firmware/acpi/interrupts/* on 2.6.32.10
Comment 7 Wojo 2010-04-01 23:21:42 UTC
Created attachment 25811 [details]
powertop -d on ac on 2.6.32.10
Comment 8 Wojo 2010-04-01 23:22:40 UTC
Created attachment 25812 [details]
powertop -d on battery on 2.6.32.10
Comment 9 Wojo 2010-04-01 23:23:09 UTC
Created attachment 25813 [details]
lspci on 2.6.32.10
Comment 10 Wojo 2010-04-01 23:31:07 UTC
Created attachment 25814 [details]
dmidecode on 2.6.32.10
Comment 11 Wojo 2010-04-01 23:32:56 UTC
Oh and one more thing - i should explain why 2.6.31.6.
I use this specific kernel because it is last working properly version in Arch Linux system.
Comment 12 Stefano 2010-04-02 07:24:23 UTC
did work for you the idle=halt ?
It did for me (for wakeups) but Temperature is a bit (3/4C) higher
than the T on kernel 2.6.31.x...
Comment 13 Wojo 2010-04-02 17:08:53 UTC
Good evening.

As i said earlier i were going to test 2.6.34-x kernel and "idle=halt" parameter.
The results are following:
- with 2.6.34-rc3 wakeups from idle per second are still very high,
- with 2.6.34-rc3 and "idle=halt" wakeups from idle per second are low.

I don't know what about temperatures, because i am having some issues with "coretemp" with that custom kernel.

I'm attaching few outputs...
Comment 14 Wojo 2010-04-02 17:21:07 UTC
Created attachment 25822 [details]
powertop -d on ac on 2.6.34-rc3
Comment 15 Wojo 2010-04-02 17:34:25 UTC
Created attachment 25823 [details]
powertop -d on ac on 2.6.34-rc3 with idle=halt
Comment 16 Wojo 2010-04-02 17:41:58 UTC
Created attachment 25824 [details]
powertop -d on battery on 2.6.34-rc3
Comment 17 Wojo 2010-04-02 18:16:23 UTC
Created attachment 25825 [details]
powertop -d on battery on 2.6.34-rc3 with idle=halt
Comment 18 Wojo 2010-04-02 18:17:06 UTC
Created attachment 25826 [details]
/sys/firmware/acpi/interrupts/* on 2.6.34-rc3
Comment 19 Wojo 2010-04-02 18:17:28 UTC
Created attachment 25827 [details]
/sys/firmware/acpi/interrupts/* on 2.6.34-rc3 with idle=halt
Comment 20 Len Brown 2010-04-03 21:13:14 UTC
This looks exactly like bug 14742.

Linux 2.6.31 uses C1 and avoids C2.
Linux 2.6.32 (and later) includes a logic update in cpuidle
which causes it to use C2 and thrash with C0 time and huge wakeups/sec.

(Thus, marking this as a regression, even though it is because
 2.6.32 has exposed a latent bug)

"idle=halt" works around the problem.
Please verify that "processor.max_cstate=1" also
works around the problem. (it is like idle=halt,
but will allow using mwait in C1 instead of HLT)

> Intel Pentium Dual Core T2370 @1.73GHz

Please paste here the output from "cat /proc/cpuinfo"

Also, regarding bug 15377 -- that one is similar, but
has some differences.  Please boot without enabling
the network interfaces and run powertop -d to see if
the problem is still there.  If no, then enable the network
and if that provokes the failure.

On a failing kernel, please attach the output from "dmesg -s64000".
Please attach the standard output from acpidump,
plus a copy of the files in /sys/firmware/acpi/tables/dynamic/*

Finally, if you happen to have a Windows partition on this box,
please run perfmon, add the C2 counter and report what you see.
Comment 21 Wojo 2010-04-03 23:01:26 UTC
I am attaching needed files...
Please note that, even without networking modules wakeups are still high.

"processor.max_cstate=1" like "idle=halt" workarounds this issue.

Unfortunately, i can't help with Windows part. I don't have any other operating system on this computer.

/proc/cpuinfo :
[wojo@cytrynka:~]$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Pentium(R) Dual  CPU  T2370  @ 1.73GHz
stepping	: 13
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips	: 3458.61
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Pentium(R) Dual  CPU  T2370  @ 1.73GHz
stepping	: 13
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips	: 3459.09
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
Comment 22 Wojo 2010-04-03 23:05:16 UTC
Created attachment 25839 [details]
Copy of files from /sys/firmware/acpi/tables/dynamic/* (2.6.32.10, high number of wakeups)
Comment 23 Wojo 2010-04-03 23:06:41 UTC
Created attachment 25840 [details]
dmesg -s64000 on 2.6.32.10 (high number of wakeups)
Comment 24 Wojo 2010-04-03 23:08:06 UTC
Created attachment 25841 [details]
acpidump on 2.6.32.10 (high number of wakeups)
Comment 25 Wojo 2010-04-03 23:13:17 UTC
Created attachment 25842 [details]
lsmod on 2.6.32.10 after booting without netowrking

I added tg3 and iwl3945 to mod blacklist to avoid loading them.
I booted kernel 2.6.32.10 with high number of wakeups results.
Comment 26 Wojo 2010-04-03 23:19:21 UTC
My bad, i forgot to add kernel version to attachments.
I've already updated attachments descriptions. 

"Copy of files from /sys/firmware/acpi/tables/dynamic/*" and 
"dmesg -s64000 on 2.6.32.10" were also running on failing kernel.
Comment 27 Len Brown 2010-04-04 05:44:08 UTC
> ACPI: BIOS _OSI(Linux) query ignored

BTW. do you notice any change booting with "acpi_osi=Linux",
such as in the battery reporting?
Comment 28 Wojo 2010-04-04 11:08:47 UTC
Created attachment 25844 [details]
dmesg -s64000 on 2.6.32.10 with acpi_osi=Linux and processor.max_cstate=1

There is less info from ACPI in dmesg after booting with acpi_osi=Linux

But it's hard to say, everything seems be normal (like /proc/acpi/battery/*).
Where could i find more informations?
Comment 29 Zhang Rui 2010-06-09 06:34:51 UTC
does the problem still exists in the latest upstream kernel?
Comment 30 Zhang Rui 2010-06-30 06:10:59 UTC
close this bug as there is no response from the bug reporter.