-----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

-----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PGNet Dev wrote:

jeff,

On Sun, Aug 2, 2009 at 10:16 PM, Jeff Mahoney 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

jan, On Mon, Aug 3, 2009 at 12:34 AM, Jan Beulich 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

...

...

Jeff Mahoney 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

Le lundi 03 août 2009, Jeff Mahoney a écrit :

Jan Beulich wrote:

...

...

...

...

Jeff Mahoney 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