Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#33747 - Incorrect CPU frequency reported when overclocked and using frequency scaling
Attached to Project:
Arch Linux
Opened by Marisa Kirisame (Sayachan) - Thursday, 07 February 2013, 11:00 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 09 February 2013, 07:44 GMT
Opened by Marisa Kirisame (Sayachan) - Thursday, 07 February 2013, 11:00 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 09 February 2013, 07:44 GMT
|
DetailsDescription:
When overclocking the CPU and also having frequency scaling enabled (Intel SpeedStep on the BIOS in this case), the kernel still shows the stock speeds. It seems this is only a visual problem, since the calculated BogoMIPS, for example, is correct. If I disable frequency scaling, this problem does not happen. This has been happening for quite a long while, can't really remember since what kernel version. Additional info: Here are the contents of /proc/cpuinfo - Frequency scaling enabled: http://sprunge.us/OeNZ - Frequency scaling disabled: http://sprunge.us/PJYJ The stock speed of my Q8400 is 2.66GHz, I have the FSB changed from 333 to 395MHz, so the actual speed should be 3.16GHz. It seems this has been also reported in other places, although not resolved: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/379873 Steps to reproduce: Changing the FSB clock speed and enabling frequency scaling on the BIOS, while on Linux, at any load the frequency reported by the kernel should be incorrect. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Saturday, 09 February 2013, 07:44 GMT
Reason for closing: Not a bug
Saturday, 09 February 2013, 07:44 GMT
Reason for closing: Not a bug
When you load cpufreq, /proc/cpuinfo shows whatever is retrieved from the cpufreq subsystem, so that explains why that value is wrong too.