[opensuse-kernel] kernel & BIOS report (incorrectly?) different current/available speeds for overclocked CPU
i've built up a new openSUSE server on a mobo: ASUS M3A78-CM, BIOS r1903 cpu: AMD 2.8GHz Phenom II X4 920 (Black) @ BIOS, i've overclocked the CPU by 33% from 2.8Hz -> 1.33 x 2.*8 = 3.7GHz. booting to OS, the reported(/available) CPU freq is NOT that which the BIOS reports. questions: (1) is this a bug, or expected behavior for OC'ing? (2) if a bug, is it in kernel, or BIOS? (3) if not a bug, how does one monitor _actual_ CPU speed in openSUSE? details ... uname -a Linux server 2.6.27.25-0.1-default #1 SMP 2009-07-01 15:37:09 +0200 x86_64 x86_64 x86_64 GNU/Linux checking, cpufreq-info cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to http://bugs.opensuse.org, please. analyzing CPU 0: driver: powernow-k8 CPUs which need to switch frequency at the same time: 0 hardware limits: 800 MHz - 2.80 GHz available frequency steps: 2.80 GHz, 2.10 GHz, 1.60 GHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 800 MHz and 2.80 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 2.80 GHz (asserted by call to hardware). (and similar for ...) analyzing CPU 1: analyzing CPU 2: analyzing CPU 3: and cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 920 Processor stepping : 2 cpu MHz : 2800.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 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 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips : 7448.31 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate (and similar for ...) processor : 1 processor : 2 processor : 3 note that only 2.8GHz ('stock' CPU speed) is available as a cpufreq option ... not trace of the ~ 3.7 GHz "actual" OC'd speed. checking @ #irc, others (with other mobos, OS versions, configs, etc) claim that BIOS clock speed == cpufreq-reported clock speed. any pointers are appreciated! thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
just a bit more info ... disabling AMD's "Cool n Quiet" processor scaling support in BIOS, verifying no scaling support, cpufreq-info cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to http://bugs.opensuse.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU analyzing CPU 1: no or unknown cpufreq driver is active on this CPU analyzing CPU 2: no or unknown cpufreq driver is active on this CPU analyzing CPU 3: no or unknown cpufreq driver is active on this CPU now CPU processor shows @ OS correctly, cat /proc/cpuinfo | egrep "MHz|bogomips" cpu MHz : 3724.127 bogomips : 7448.24 cpu MHz : 3724.127 bogomips : 7448.40 cpu MHz : 3724.127 bogomips : 7448.49 cpu MHz : 3724.127 bogomips : 7448.46 but note that the bogomips results are the same as in my OP for the reported 2.8GHz operation ... confusion abounds! :-/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Sun, Aug 02, 2009 at 11:27:57AM -0700, PGNet Dev wrote:
i've built up a new openSUSE server on a
mobo: ASUS M3A78-CM, BIOS r1903 cpu: AMD 2.8GHz Phenom II X4 920 (Black)
@ BIOS, i've overclocked the CPU by 33% from 2.8Hz -> 1.33 x 2.*8 = 3.7GHz.
Then you are totally on your own, sorry. Best of luck, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Sun, Aug 2, 2009 at 8:08 PM, Greg KH<gregkh@suse.de> wrote:
On Sun, Aug 02, 2009 at 11:27:57AM -0700, PGNet Dev wrote:
i've built up a new openSUSE server on a
mobo: ASUS M3A78-CM, BIOS r1903 cpu: AMD 2.8GHz Phenom II X4 920 (Black)
@ BIOS, i've overclocked the CPU by 33% from 2.8Hz -> 1.33 x 2.*8 = 3.7GHz.
Then you are totally on your own, sorry.
Best of luck,
greg k-h
i'm sorry, what exactly is your point? i'm seeing differences in opensuse reported speed, and bios reported speed. overclocking is enabled by both AMD and ASUS. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
On Sun, Aug 02, 2009 at 11:27:57AM -0700, PGNet Dev wrote:
i've built up a new openSUSE server on a
mobo: ASUS M3A78-CM, BIOS r1903 cpu: AMD 2.8GHz Phenom II X4 920 (Black)
@ BIOS, i've overclocked the CPU by 33% from 2.8Hz -> 1.33 x 2.*8 = 3.7GHz.
Then you are totally on your own, sorry.
True, but we should still be reporting the real speed if the hardware does. To the original poster: In an environment that is based around sharing and open standards, anonymous emails don't encourage people to respond favorably. To answer your other question: even if the tool reported your CPU speed accurately, any problems you report with that configuration will be ignored. The hardware would be operating out of spec and any guarantees that the software would be operating properly go right out the window. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkp2XkUACgkQLPWxlyuTD7LFSwCeInmgxImtAk6qV0EU1dF1Kgsn mUwAoIgv0lc2YZtGstNiNfodHyAzlJiG =vNYt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Then you are totally on your own, sorry.
True, but we should still be reporting the real speed if the hardware does.
the problem exists with any/all speeds above the 'stock' 2.8 GHz .... if, given the responses above and below you're actually interested in more data, i can provide coremark benchmarks in both cases showing virtually identical results in both cases. i.e., despite the OS's report that the cpu speed is "2.8GHz", it's actually still at the BIOS-reported 3.7 GHZ.
To the original poster: In an environment that is based around sharing and open standards, anonymous emails don't encourage people to respond favorably.
hardly anonymous ... but, huh? anonimity justifies rudeness? you need to be "encouraged" to politely respond to community members (lets forget paying customers, for the moment) trying to be helpful?
To answer your other question: even if the tool reported your CPU speed accurately, any problems you report with that configuration will be ignored. The hardware would be operating out of spec and any guarantees that the software would be operating properly go right out the window.
so overclocking of any kind in UNsupported by *suse and will be ignored? that'll be news to quite a few folks, i'd presume ... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PGNet Dev wrote:
Then you are totally on your own, sorry. True, but we should still be reporting the real speed if the hardware does.
the problem exists with any/all speeds above the 'stock' 2.8 GHz .... if, given the responses above and below you're actually interested in more data, i can provide coremark benchmarks in both cases showing virtually identical results in both cases. i.e., despite the OS's report that the cpu speed is "2.8GHz", it's actually still at the BIOS-reported 3.7 GHZ.
Yes, that's what I consider to be the bug here. If it's running at 3.7 GHz and performing at 3.7 GHz, that's important.
To the original poster: In an environment that is based around sharing and open standards, anonymous emails don't encourage people to respond favorably.
hardly anonymous ... but, huh? anonimity justifies rudeness? you need to be "encouraged" to politely respond to community members (lets forget paying customers, for the moment) trying to be helpful?
Overclocking is a sensitive topic. It can introduce stability problems that are reported as normal bugs when they are most definitely not. After you see a bunch of them, it's easy to get a little jumpy. Don't take it personally. A stable email address doesn't mean you're not anonymous. Communities are built on trust. In the kernel community, we sign off code patches with our names and email addresses. I don't think it's too much to ask for reporters to do the same. If you're not submitting code, I don't care if you use a pseudonym. I want to be able to be able to say "Hi" at the beginning of an email and have it be an actual name. If you do submit code and use a pseudonym then you're definitely not part of the community.
To answer your other question: even if the tool reported your CPU speed accurately, any problems you report with that configuration will be ignored. The hardware would be operating out of spec and any guarantees that the software would be operating properly go right out the window.
so overclocking of any kind in UNsupported by *suse and will be ignored? that'll be news to quite a few folks, i'd presume ...
If you're operating outside of parameters that the hardware vendors define, absolutely! - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkp2crYACgkQLPWxlyuTD7KXWwCgilTfjW/D+ls2jFL6nVOYCz0C QD0An3HidY6tA7LsBuS4GTlbTjeY0tNX =EkPJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
jeff, On Sun, Aug 2, 2009 at 10:16 PM, Jeff Mahoney<jeffm@suse.com> wrote:
the problem exists with any/all speeds above the 'stock' 2.8 GHz .... if, given the responses above and below you're actually interested in more data, i can provide coremark benchmarks in both cases showing virtually identical results in both cases. i.e., despite the OS's report that the cpu speed is "2.8GHz", it's actually still at the BIOS-reported 3.7 GHZ.
Yes, that's what I consider to be the bug here. If it's running at 3.7 GHz and performing at 3.7 GHz, that's important.
here's the salient, supporting info ... running COREMARK (http://coremark.org) benchmark, cd /usr/local/src/coremark_v1.0/ make clean make XCFLAGS="-DMULTITHREAD=4 -DUSE_PTHREAD" REBUILD=1 ITERATIONS=1000000 in each of three cases, (1) Asus' "Cool n Quiet" OFF, CPU OC'd to 3.7 GHz, OS reports 3.7 GHz (2) Asus' "Cool n Quiet" ON, CPU OC'd to 3.7 GHz, OS reports 2.8 GHz (3) Asus' "Cool n Quiet" ON, CPU @ stock 2.8 GHz, OS reports 2.8 GHz note, in particular, the "Iterations/sec" in the data below, are (1) 46521.906002 (2) 46419.329009 (3) 34996.544091 clearly, (1) & (2) are about the same. asuming the stock data, (3) is correct for 2.8Ghz, and that (3) x 1.33 ~= 46544, sure seems like (2) is -- in fact -- misreported by the OS. (1) cat /proc/cpuinfo | grep MHz cpu MHz : 3724.163 cpu MHz : 3724.163 cpu MHz : 3724.163 cpu MHz : 3724.163 cat coremark_v1.0/run{1,2}.log ------------------------------------ 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 85981 Total time (secs): 85.981000 Iterations/Sec : 46521.906002 Iterations : 4000000 Compiler version : GCC4.3.2 [gcc-4_3-branch revision 141291] Compiler flags : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 -lrt Parallel PThreads : 4 ... Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 46521.906002 / GCC4.3.2 [gcc-4_3-branch revision 141291] -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 -lrt / Heap / 4:PThreads 2K validation run parameters for coremark. CoreMark Size : 666 Total ticks : 112348 Total time (secs): 112.348000 Iterations/Sec : 35603.660056 Iterations : 4000000 Compiler version : GCC4.3.2 [gcc-4_3-branch revision 141291] Compiler flags : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DVALIDATION_RUN=1 -lrt Parallel PThreads : 4 ... ------------------------------------ (2) 3.8GHz COOL-n-QUIET ENABLED cat /proc/cpuinfo | grep MHz cpu MHz : 2800.000 cpu MHz : 2800.000 cpu MHz : 2800.000 cpu MHz : 2800.000 cd /usr/local/src/coremark_v1.0/ rm run{1,2}.log make clean make XCFLAGS="-DMULTITHREAD=4 -DUSE_PTHREAD" REBUILD=1 ITERATIONS=1000000 cat coremark_v1.0/run{1,2}.log ------------------------------------ 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 86171 Total time (secs): 86.171000 Iterations/Sec : 46419.329009 Iterations : 4000000 Compiler version : GCC4.3.2 [gcc-4_3-branch revision 141291] Compiler flags : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 -lrt Parallel PThreads : 4 ... Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 46419.329009 / GCC4.3.2 [gcc-4_3-branch revision 141291] -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 -lrt / Heap / 4:PThreads 2K validation run parameters for coremark. CoreMark Size : 666 Total ticks : 102823 Total time (secs): 102.823000 Iterations/Sec : 38901.802126 Iterations : 4000000 Compiler version : GCC4.3.2 [gcc-4_3-branch revision 141291] Compiler flags : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DVALIDATION_RUN=1 -lrt Parallel PThreads : 4 ... ------------------------------------ (3) "STOCK" 2.8GHz COOL-n-QUIET ENABLED cat /proc/cpuinfo | grep MHz cpu MHz : 2800.000 cpu MHz : 2800.000 cpu MHz : 2800.000 cpu MHz : 2800.000 cd /usr/local/src/coremark_v1.0/ rm run{1,2}.log make clean make XCFLAGS="-DMULTITHREAD=4 -DUSE_PTHREAD" REBUILD=1 ITERATIONS=1000000 cat coremark_v1.0/run{1,2}.log ------------------------------------ 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 114297 Total time (secs): 114.297000 Iterations/Sec : 34996.544091 Iterations : 4000000 Compiler version : GCC4.3.2 [gcc-4_3-branch revision 141291] Compiler flags : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 -lrt Parallel PThreads : 4 ... CoreMark 1.0 : 34996.544091 / GCC4.3.2 [gcc-4_3-branch revision 141291] -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 -lrt / Heap / 4:PThreads 2K validation run parameters for coremark. CoreMark Size : 666 Total ticks : 113871 Total time (secs): 113.871000 Iterations/Sec : 35127.468802 Iterations : 4000000 Compiler version : GCC4.3.2 [gcc-4_3-branch revision 141291] Compiler flags : -O2 -DMULTITHREAD=4 -DUSE_PTHREAD -DVALIDATION_RUN=1 -lrt Parallel PThreads : 4 ... ------------------------------------
Overclocking is a sensitive topic. It can introduce stability problems that are reported as normal bugs when they are most definitely not. After you see a bunch of them, it's easy to get a little jumpy. Don't take it personally.
I appreciate your candor. But to be honest, nothing WAS reported as a bug here. I asked succinctly and politely *here*, on the community list, if it is, or is not. Before filing a bug. For _exactly_ the purpose of NOT reporting a bug if it is not. As for taking it personally -- sorry, I do take rudeness personally. Don't you?
A stable email address doesn't mean you're not anonymous. Communities are built on trust. In the kernel community, we sign off code patches with our names and email addresses. I don't think it's too much to ask for reporters to do the same. If you're not submitting code, I don't care if you use a pseudonym. I want to be able to be able to say "Hi" at the beginning of an email and have it be an actual name. If you do submit code and use a pseudonym then you're definitely not part of the community.
(1) i've submitted dozens of bugs, using my email address above -- with which i'm registered at Novell -- and have stuck around to work through them with the developers. on list, on bugzilla, on irc, on phone, and face to face. iirc, you have responded to at least a couple of them. (2) as for wanting to "say hi" at the beginning of an email, fine. apart from the fact that you and i have _personally_ exchanged email off list a number of times -- what you _want_ deserves no more or less weight than what i want, which is to manage my communication in a way that works for me. neither case justifies 'jumpy' or 'rude'. (3) where have i submitted any code? (4) if you're going to "ask (or require) *reporters*" to only use their names in/on public forums, then you might actually announce that as policy somewhere, enforce it @Novell/Suse forums, lists, bugizlla, etc and try to do that before making presumptions.
so overclocking of any kind in UNsupported by *suse and will be ignored? that'll be news to quite a few folks, i'd presume ...
If you're operating outside of parameters that the hardware vendors define, absolutely!
if you choose not to support ANY overclocking of ANY hardware because it's not the "official" spec, well ... kind of makes you wonder what AMD annd ASUS are thinking actually building hardware & software to make overclocking beyond 'stock', out of the box params possible. not worth the argument to me. i politely asked a question. and diligently offered what info i could. if you don't want to hear it -- fine. your product's loss, ultimately. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PGNet Dev wrote:
jeff,
On Sun, Aug 2, 2009 at 10:16 PM, Jeff Mahoney<jeffm@suse.com> wrote:
the problem exists with any/all speeds above the 'stock' 2.8 GHz .... if, given the responses above and below you're actually interested in more data, i can provide coremark benchmarks in both cases showing virtually identical results in both cases. i.e., despite the OS's report that the cpu speed is "2.8GHz", it's actually still at the BIOS-reported 3.7 GHZ. Yes, that's what I consider to be the bug here. If it's running at 3.7 GHz and performing at 3.7 GHz, that's important. (1) Asus' "Cool n Quiet" OFF, CPU OC'd to 3.7 GHz, OS reports 3.7 GHz (2) Asus' "Cool n Quiet" ON, CPU OC'd to 3.7 GHz, OS reports 2.8 GHz (3) Asus' "Cool n Quiet" ON, CPU @ stock 2.8 GHz, OS reports 2.8 GHz
Huh, so CnQ might be the problem here. I'm not a CPU expert so I can't really say why that would be. Jan responded in another post that the ACPI tables might not be able to report it - but then we have the non-CnQ number reporting accurately.
Overclocking is a sensitive topic. It can introduce stability problems that are reported as normal bugs when they are most definitely not. After you see a bunch of them, it's easy to get a little jumpy. Don't take it personally.
I appreciate your candor. But to be honest, nothing WAS reported as a bug here. I asked succinctly and politely *here*, on the community list, if it is, or is not. Before filing a bug. For _exactly_ the purpose of NOT reporting a bug if it is not.
My view is that the misreporting is a bug, but anything you do with it isn't.
As for taking it personally -- sorry, I do take rudeness personally. Don't you?
A stable email address doesn't mean you're not anonymous. Communities are built on trust. In the kernel community, we sign off code patches with our names and email addresses. I don't think it's too much to ask for reporters to do the same. If you're not submitting code, I don't care if you use a pseudonym. I want to be able to be able to say "Hi" at the beginning of an email and have it be an actual name. If you do submit code and use a pseudonym then you're definitely not part of the community.
(1) i've submitted dozens of bugs, using my email address above -- with which i'm registered at Novell -- and have stuck around to work through them with the developers. on list, on bugzilla, on irc, on phone, and face to face. iirc, you have responded to at least a couple of them. (2) as for wanting to "say hi" at the beginning of an email, fine. apart from the fact that you and i have _personally_ exchanged email off list a number of times -- what you _want_ deserves no more or less weight than what i want, which is to manage my communication in a way that works for me. neither case justifies 'jumpy' or 'rude'.
You're absolutely right that you have the right to manage your communication the way you want. I still don't think Greg was being rude when he said it was unsupported, though. Terse, maybe, but not rude.
(3) where have i submitted any code?
That's not what I was saying, but it could come across that way. I meant that it's fine to use a pseudonym if you're never planning on submitting code.
(4) if you're going to "ask (or require) *reporters*" to only use their names in/on public forums, then you might actually announce that as policy somewhere, enforce it @Novell/Suse forums, lists, bugizlla, etc and try to do that before making presumptions.
I'm not. It's not an official policy, it's my opinion. I might have expressed it a little too strongly.
so overclocking of any kind in UNsupported by *suse and will be ignored? that'll be news to quite a few folks, i'd presume ... If you're operating outside of parameters that the hardware vendors define, absolutely!
if you choose not to support ANY overclocking of ANY hardware because it's not the "official" spec, well ... kind of makes you wonder what AMD annd ASUS are thinking actually building hardware & software to make overclocking beyond 'stock', out of the box params possible.
not worth the argument to me.
i politely asked a question. and diligently offered what info i could. if you don't want to hear it -- fine. your product's loss, ultimately.
AMD and ASUS offer those products because users are looking to push the envelope and _will pay for them_. They're in the business of selling hardware and there's a market for it. Sometimes it works due to higher quality processors being released at a certain frequency and sometimes it introduces massive instability. As part of the community which is responsible for triaging and fixing bugs, Greg and I are concerned that overclocking just introduces one more variable that is totally outside software control. It's no different than our refusal to support binary-only modules. Either of them can introduce subtle or not so subtle corruptions that lead to crashes in otherwise stable software. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkp29OsACgkQLPWxlyuTD7Ji+ACgmMe9yxtQrgXf7hyY8jlUZwV5 hQcAoIYSsrilNBiJCnVCqD06iOsnioaT =wEKO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
PGNet Dev <pgnet.dev+oskrn@gmail.com> 02.08.09 20:27 >>> i've built up a new openSUSE server on a
mobo: ASUS M3A78-CM, BIOS r1903 cpu: AMD 2.8GHz Phenom II X4 920 (Black)
@ BIOS, i've overclocked the CPU by 33% from 2.8Hz -> 1.33 x 2.*8 = 3.7GHz.
booting to OS, the reported(/available) CPU freq is NOT that which the BIOS reports.
questions:
(1) is this a bug, or expected behavior for OC'ing? (2) if a bug, is it in kernel, or BIOS?
BIOS: Both this
available frequency steps: 2.80 GHz, 2.10 GHz, 1.60 GHz, 800 MHz
and (presumably, as you didn't show it) /var/log/messages would confirm this. The identifiers for the corresponding frequencies are stored in ACPI tables and/or MSRs, so if the BIOS "supported" overclocking, it would have to update these tables/registers (the actual frequencies get calculated from these identifiers). The value /proc/cpuinfo reports is simply one of the frequencies reported as available. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
jan, On Mon, Aug 3, 2009 at 12:34 AM, Jan Beulich<JBeulich@novell.com> wrote:
(1) is this a bug, or expected behavior for OC'ing? (2) if a bug, is it in kernel, or BIOS?
BIOS: Both this
available frequency steps: 2.80 GHz, 2.10 GHz, 1.60 GHz, 800 MHz
and (presumably, as you didn't show it) /var/log/messages would confirm this. The identifiers for the corresponding frequencies are stored in ACPI tables and/or MSRs, so if the BIOS "supported" overclocking, it would have to update these tables/registers (the actual frequencies get calculated from these identifiers).
The value /proc/cpuinfo reports is simply one of the frequencies reported as available.
thanks for clarifying how this works. i'll take it up with the mobo vendor. thanks again ! -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Beulich wrote:
PGNet Dev <pgnet.dev+oskrn@gmail.com> 02.08.09 20:27 >>> i've built up a new openSUSE server on a
mobo: ASUS M3A78-CM, BIOS r1903 cpu: AMD 2.8GHz Phenom II X4 920 (Black)
@ BIOS, i've overclocked the CPU by 33% from 2.8Hz -> 1.33 x 2.*8 = 3.7GHz.
booting to OS, the reported(/available) CPU freq is NOT that which the BIOS reports.
questions:
(1) is this a bug, or expected behavior for OC'ing? (2) if a bug, is it in kernel, or BIOS?
BIOS: Both this
available frequency steps: 2.80 GHz, 2.10 GHz, 1.60 GHz, 800 MHz
and (presumably, as you didn't show it) /var/log/messages would confirm this. The identifiers for the corresponding frequencies are stored in ACPI tables and/or MSRs, so if the BIOS "supported" overclocking, it would have to update these tables/registers (the actual frequencies get calculated from these identifiers).
The value /proc/cpuinfo reports is simply one of the frequencies reported as available.
The thing is that the non-CnQ mode is reported as 3.7 GHz. I don't know enough about CnQ to know why that is - but values outside of the original tables are getting reported if we're seeing the 3.7 GHz there. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkp29TYACgkQLPWxlyuTD7L0JQCfWOK86nMY2u4o+FGIxi7oWudq Qf8An2AVfnTC1IvVWwXrPDY6/04+H3Dt =qTYr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney <jeffm@suse.com> 03.08.09 16:33 >>> The thing is that the non-CnQ mode is reported as 3.7 GHz. I don't know enough about CnQ to know why that is - but values outside of the original tables are getting reported if we're seeing the 3.7 GHz there.
What "original tables" are you referring to? The 3.7 GHz is a measured value, not one read from any tables. All the frequencies the powernow driver reports are table derived (and hence susceptible to BIOS issues). Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Beulich wrote:
Jeff Mahoney <jeffm@suse.com> 03.08.09 16:33 >>> The thing is that the non-CnQ mode is reported as 3.7 GHz. I don't know enough about CnQ to know why that is - but values outside of the original tables are getting reported if we're seeing the 3.7 GHz there.
What "original tables" are you referring to? The 3.7 GHz is a measured value, not one read from any tables. All the frequencies the powernow driver reports are table derived (and hence susceptible to BIOS issues).
The ACPI tables you mentioned in your previous post. Maybe I misunderstood. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkp3NRAACgkQLPWxlyuTD7I6pQCgkG2jnXx+P7jAoACznfiMy5eO SfgAn2al4ShYk7BfVZdfhQ2Mm9yMgnML =/eR2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le lundi 03 août 2009, Jeff Mahoney a écrit :
Jan Beulich wrote:
Jeff Mahoney <jeffm@suse.com> 03.08.09 16:33 >>> The thing is that the non-CnQ mode is reported as 3.7 GHz. I don't know enough about CnQ to know why that is - but values outside of the original tables are getting reported if we're seeing the 3.7 GHz there.
What "original tables" are you referring to? The 3.7 GHz is a measured value, not one read from any tables. All the frequencies the powernow driver reports are table derived (and hence susceptible to BIOS issues).
The ACPI tables you mentioned in your previous post. Maybe I misunderstood.
It's quite some time since I last played with cpufreq, but I think it can be explained that way: * Asus' Cool'n'Quiet is essentially AMD's PowerNow! rebranded. That is, an implementation of cpufreq. * When cpufreq is not used, the frequency reported in /proc/cpuinfo is the one measured at boot time. * When cpufreq is used, the frequency measured at boot time is no longer relevant as we _know_ it will change over time. So the frequency reported in /proc/cpuinfo is provided by the cpufreq driver and changes dynamically. It's relatively easy to differentiate between these cases by just looking at the frequency value. Measured ones have varying digits, while cpufreq-provided ones always end with zeroes: cpu MHz : 1996.939 versus cpu MHz : 1000.000 So basically, incorrect frequency tables from the BIOS have no effect when cpufreq/CnQ/PowerNow is not used. And my conclusion is the same as Jan's: the vendor offers overclocking capabilities as a selling argument, but did not actually design its BIOS to handle it properly. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (5)
-
Greg KH -
Jan Beulich -
Jean Delvare -
Jeff Mahoney -
PGNet Dev