Bug 54541 - Cpu frequency don't work in conky with kernel 3.9.0.0.rc0.git8
Summary: Cpu frequency don't work in conky with kernel 3.9.0.0.rc0.git8
Status: CLOSED INVALID
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Aaron Lu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-27 07:32 UTC by chepioq
Modified: 2013-03-11 00:45 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.9.0.0.rc0.git8
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description chepioq 2013-02-27 07:32:47 UTC
I use fedora, and test fedora 19 rawhide.
I use conky, and see with him cpu frequencies.

With kernel 3.8, that work fine, I can see my cpu frequencies, 800Mhz to 2300 Mhz, but with kernel 3.9.0.0, that don't work, I just can see 782 Mhz, with no change.
I don't if it's a kernel bug or a fedora bug.
Comment 1 chepioq 2013-02-27 07:41:37 UTC
For info a cat /proc/cpuinfo return same result : 

[dominique@host ~]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 782.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
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 nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4589.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           : 42
model name      : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 782.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
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 nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4589.61
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 782.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
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 nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4589.61
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 782.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
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 nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4589.61
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

[dominique@host ~]$
Comment 2 Aaron Lu 2013-02-28 01:24:33 UTC
Hi chepioq,

Thanks for reporting the problem.
Can you please try Linus' git tree? And do a git bisect from tag v3.8 to the current head to see which commit introduced this bug? Thanks.
Comment 3 chepioq 2013-02-28 05:56:56 UTC
Hi Aaron,
I don't know how doing a git bisect.

And I don't see a 3.9 kernel on kernel.org...
Comment 4 Aaron Lu 2013-02-28 06:06:38 UTC
Hi chepioq,

3.9 is still under development and not released yet :-)

Do you know how to use git to clone code and how to build kernel? If so, you can follow the document here to begin:
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search

Please let me know if you have other problems, thanks.
Comment 5 chepioq 2013-02-28 06:40:39 UTC
Ok
I download git, but I don't find 3.9.

I do :
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git
cd linux-git
git bisect start
git bisect good v3.8

For that that's good but : 
git bisect bad v3.9
fatal: Needed a single revision
Bad rev input: v3.9

What is name of 3.9 in git ?
Comment 6 Aaron Lu 2013-02-28 06:45:43 UTC
Please test the cloned tree first, and if it has the problem, you can simply type:
$ git bisect bad
Which tells git the current HEAD of the tree is bad.

v3.9 is not released yet, in the same way that fedora 19 is not released yet either, but we already call it that way :-)
Comment 7 chepioq 2013-02-28 06:50:25 UTC
output of git bisect bad

[dominique@chepioq linux-git]$ git bisect bad
Bisecting: 4882 revisions left to test after this (roughly 12 steps)
[b5c78e04dd061b776978dad61dd85357081147b0] Merge tag 'staging-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Comment 8 Aaron Lu 2013-02-28 06:53:34 UTC
Right, please go ahead build the kernel, and then test it. If it failed, mark it so by:
$ git bisect bad
And if it's OK, mark it as:
$ git bisect good
And repeat the procedure till it reports the first bad commit. Thanks.
Comment 9 chepioq 2013-02-28 17:44:54 UTC
Ok, but I use my laptop for job, and build a kernel take a long time, there are 4882 revisions to test, may be 12 or 13 kernels...
Comment 10 Aaron Lu 2013-03-01 00:56:45 UTC
(In reply to comment #9)
> Ok, but I use my laptop for job, and build a kernel take a long time, there
> are
> 4882 revisions to test, may be 12 or 13 kernels...

Yes, take your time, no hurry.
Thanks.
Comment 11 chepioq 2013-03-04 18:14:05 UTC
Hi Aaron.

Good new for you (and bad for me), I do all the gitbisect, and there is no gitbisect bad.

The problem is not with the kernel, but maybe with the kernel from fedora (or one of the patches they include)...

Sorry for the inconvenience...

Chepioq
Comment 12 Dirk Brandewie 2013-03-04 22:08:45 UTC
The rawhide kernel has my intel_pstate driver for sandybridge enabled.  The value returned is the effective frequency the core ran at last time it was sampled so the value see will likely not be the nice even numbers you are used to seeing.

Do you see the frequencies changing if there is a load on the system?

I have also replied to:
https://bugzilla.redhat.com/show_bug.cgi?id=916833

--Dirk
Comment 13 chepioq 2013-03-05 05:59:22 UTC
When the system is loaded, the frequency don't change and stay on 782 value.

With my conky, I can see cpu occupancy rate which varies, but frequency don't change.
Comment 14 Aaron Lu 2013-03-08 02:13:15 UTC
Hi Dirk,

Shall I assign this bug to you? Or you want to track it in the redhat's bugzilla?
Comment 15 Dirk Brandewie 2013-03-08 23:34:45 UTC
I would like to track this in the Fedora bugzilla.  I haven't been able to reproduce it yet
Comment 16 Aaron Lu 2013-03-11 00:45:56 UTC
(In reply to comment #15)
> I would like to track this in the Fedora bugzilla.  I haven't been able to
> reproduce it yet

OK, thanks.
I'll close it here, since it's not in upstream yet.

Note You need to log in before you can comment on or make changes to this bug.