| Summary: | 2.6.16 series of kernel doesn't show real cpu frequency | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Paulo <paulocic> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | VERIFIED UPSTREAM | ||
| Severity: | minor | CC: | esigra, paulocic, radek |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://bugzilla.kernel.org/show_bug.cgi?id=6558 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch | ||
|
Description
Paulo
2006-04-26 08:03:20 UTC
Do you have any idea where ksensors gets it's data from? You could start by comparing /proc/cpuinfo from 2.6.15 to 2.6.16, but I'm doubtful that is the data source being used here.. It's not from /proc/cpuinfo, since it's not dynamically updated. When I first configured powernow I found a file, but I couldn't find it right now, even on 2.6.15. It would display the real clock of the cpu, updated each second. It was on /proc/something... I don't know where ksensors gets it from, and I still ain't got enough programming skills to find it out by examining its sources... Ah, it is probably /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq Can you confirm the 'bug' is present when comparing the contents of that file in 2.6.15 and 2.6.16? Well... Actually, after making some more thorough investigations, I found out that I made a mistake. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is not the file I was looking for. It shows the clock the CPU should be at, and that's the bug I'm reporting, but /proc/cpuinfo IS dynamically updated, and on 2.6.15-r1 it would display the real CPU clock, regularly updated. On both cases, I was using Gentoo Sources, always the stable version, according to portage. I don't quite follow. Can you post output from those 2 files on both 2.6.15 and 2.6.15 to illustrate what you mean? This is /proc/cpuinfo for 2.6.16: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3200+ stepping : 0 cpu MHz : 1000.000 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm ts fid vid ttp bogomips : 2212.47 And this is for 2.6.15: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3200+ stepping : 0 cpu MHz : 1100.920 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm ts fid vid ttp bogomips : 2212.47 As you can see, in 2.6.16 it even shows the real bogomips, but the CPU clock shown is 1000.000MHz, which is the clock the CPU should be, but it ain't at that clock. On 2.6.15, it shows the real CPU clock, and it's really measured somewhere, because it even has decimal digits. Also on 2.6.15 it shows the bogomips right, as on 2.6.16. I know it because I know that the bogomips are usually around double the CPU clock. Is this reproducible on the latest development kernel? currently 2.6.17-rc3 Just installed portage's vanilla-sources 2.6.17_r3 and it has the same problem... Created attachment 86558 [details, diff]
patch
Please apply this patch against 2.6.17-rc3, compile, reboot into new image.
Run "cat /proc/cpuinfo" then look in the kernel logs (dmesg). It should say something along the lines of:
cpufreq says X khz is Y
Paste those lines here
/proc/cpuinfo is still showing wrong info, however, dmesg outputs this: cpufreq says 1800000 khz is 1989971 What has happened is that as of 2.6.16, /proc/cpuinfo asks cpufreq for the current frequency, and if that fails, it falls back on the old way (cpu_khz). So your bug is that cpufreq does not show the real frequency -- you should be able to confirm this by reading /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq If you want to take this bug further, you need to file a bug against 2.6.17-rc3 at http://bugzilla.kernel.org cpufreq component, reporting that it is not giving the true CPU frequency. However they may close or ignore your bug as overclocking generally isn't something that people go out of their way to support. If you do report it upstream, please post the new bug URL here. zwede on the forums has reported this upstream Filed bug report against the Linux kernal as 6558 http://bugzilla.kernel.org/show_bug.cgi?id=6558 |
