Hi Andreas, 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? Frequency scaling, this is something that is done by powersaved? And wasn't being done correctly? What were the implications of this? I have 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? Best wishes, Jon. Andreas Kleen wrote:
Am So 27.11.2005 00:26 schrieb Bernd Paysan
: On Thursday 24 November 2005 21:36, Bernd Paysan wrote:
That's the only board I've ever seen in years where I can't use PIT/TSC (on four out of seven!). There are several other Linux PCs in the office, and two at home, and all work fine with PIT/TSC, except the dual-Opteron system (running SuSE 9.3), which needs the HPET timer, since the TSC based timekeeping doesn't work with different CPUs having different speeds.
After a bit more investigation, it turned out that it is indeed the TSC-problem with dual cores. Setting the option "clock=pmtmr notsc" is mandatory on a dual-core Athlon, despite the TSC desynchronization is very small over time.
clock=pmtmr is a nop on 64bit kernels (or rather you created a "clock" variable in init's environment). The 10.0 CD kernel indeed needs notsc on single socket dual core AMD to avoid a small drift, the next update kernel will automatically enable that. All kernels from other releases should be ok.
What I don't understand is why there is any TSC desynchronization at all. The two cores run at the same frequency all the time, anyway (you can't set one to 1GHz and the other to 2GHz via Cool'n'Quiet). That's why the problem doesn't show up for a while, and some random component is necessary to see the full effect.
There is a small loss in the TSC when the cores enter/exit HLT. Depending on the workload this can add up and lead to slow drift.
Conclusion: You can't rely on the TSC if you have more than one CPU, and a power-saving policy in effect.
It depends on the system. On most Intel systems the TSC is fully synchronized for once. And the HLT loss has also nothing to do with powernow P states (if that is what you mean with "power saving policy"), but is related to C states.
It would be better to switch the stuff off automatically in that case -
That is already done now.
until AMD and Intel deliver CPUs with synchronized TSCs next year.
All 64bit Intel CPUs already have synchronized TSCs.
Or to resynchronize the TSCs after each frequency change (using the PIT or PM timer as reference then).
You're misunderstanding the issue I think. CPU frequency scaling is already handled properly at runtime.
-Andi
-- Jonathan Brooks (Ph.D.) Research Assistant. PaIN Group, Department of Human Anatomy & Genetics, University of Oxford, South Parks Road, Oxford, OX1 3QX tel: +44(0)1865-282654 fax: +44(0)1865-282656 web: http://www.fmrib.ox.ac.uk/~jon