Bug 15675
|
Description
Wojo
2010-04-01 23:13:42 UTC
Created attachment 25805 [details]
dmidecode on 2.6.31.6
Created attachment 25806 [details]
lspci on 2.6.31.6
Created attachment 25807 [details]
/sys/firmware/acpi/interrupts/* on 2.6.31.6
Created attachment 25808 [details]
powertop -d on ac on 2.6.31.6
Created attachment 25809 [details]
powertop -d on battery on 2.6.31.6
Created attachment 25810 [details]
/sys/firmware/acpi/interrupts/* on 2.6.32.10
Created attachment 25811 [details]
powertop -d on ac on 2.6.32.10
Created attachment 25812 [details]
powertop -d on battery on 2.6.32.10
Created attachment 25813 [details]
lspci on 2.6.32.10
Created attachment 25814 [details]
dmidecode on 2.6.32.10
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. 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... 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... Created attachment 25822 [details]
powertop -d on ac on 2.6.34-rc3
Created attachment 25823 [details]
powertop -d on ac on 2.6.34-rc3 with idle=halt
Created attachment 25824 [details]
powertop -d on battery on 2.6.34-rc3
Created attachment 25825 [details]
powertop -d on battery on 2.6.34-rc3 with idle=halt
Created attachment 25826 [details]
/sys/firmware/acpi/interrupts/* on 2.6.34-rc3
Created attachment 25827 [details]
/sys/firmware/acpi/interrupts/* on 2.6.34-rc3 with idle=halt
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. 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: Created attachment 25839 [details]
Copy of files from /sys/firmware/acpi/tables/dynamic/* (2.6.32.10, high number of wakeups)
Created attachment 25840 [details]
dmesg -s64000 on 2.6.32.10 (high number of wakeups)
Created attachment 25841 [details]
acpidump on 2.6.32.10 (high number of wakeups)
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.
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. > ACPI: BIOS _OSI(Linux) query ignored
BTW. do you notice any change booting with "acpi_osi=Linux",
such as in the battery reporting?
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?
does the problem still exists in the latest upstream kernel? close this bug as there is no response from the bug reporter. |