On Mon, Nov 28, 2005 at 04:17:47PM +0000, Jonathan Brooks wrote:
Can I clarify something, clock=pmtmr is a "nop"? Does this mean that the argument is not recognised by the kernel, and therefore ignored? So notsc is the *only* thing that will make a difference in SuSE10?
That is what I wrote yes. (for 64bit, it's a valid 32bit argument)
Frequency scaling, this is something that is done by powersaved? And
Yes.
wasn't being done correctly? What were the implications of this? I have
It's done correctly. Bernd's mistake was to think it was related to it (there are some other timer issues mostly on a few broken laptops related to it, but not that one)
followed the the fix suggested by Bernd in the thread "Re: [suse-amd64] BUG in powersaved: cpufreq unreliable with Athlon64 X2 (dual core)", but haven't really noticed any difference in my machine.
Last thing, should we consider AMD64X2 CPUs to be faulty? By that, I mean that if there is a revised version of the CPU in the pipeline which fixes these timing issues, should we be asking AMD for replacements?
No, in this case it was just an overeager software optimization. But they don't guarantee that the TSCs are synchronized, so software was wrong in assuming that. The update kernel will use the slower but safer timer access which avoid this. Basically it just sets notsc automatically in this case. -Andi P.S.: AFAIK as I know this is the only timer problem that is actually to blame on software. All the others are just various hardware bugs that the kernel just hasn't properly work arounded yet. Please don't ask me for details.