My notice was that it especially happend when the CPU usage grew, so I suppose it was related to the "powernow" feature of the CPU, because at least on Opteron systems SuSE's "power management" changes the CPU clock based on the load.
After I upgraded to the most recent vanilla kernel the problem was gone.
The powernow-k8 driver in SL9.3 caused clock instability on SMP machines that did not support HPET timers; SL10.0 and the mainstream kernel support PMTimer for those machines. That's most likely what you were seeing.
The single processor, dual-core problem is believed to be something different and is under investigation at AMD. We will make a statement as soon as we have definite information.
So can you confirm that the kernel options clock=pmtmr and notsc will not have any effect on this problem, and we should wait for a resolution from AMD?
I cannot confirm that. They may help. We're working on finding the answer.
I suspect that clock=pmtmr will help, for what it's worth.
Sorry for the request for clarification, but I'm stumbling around in the dark on this matter, and don't want to waste any more time on the problem - especially if it's all fruitless.
All I can officially say at this point is that AMD is aware of the problem and will be releasing a statement when we have more information.
Unofficially, clock=pmtmr should at least reduce the amount of lost ticks.
-Mark Langsdorf AMD, Inc.