On 6/1/06, Mark Whidby <[log in to unmask]> wrote: > Fabien Wernli wrote: > > On Wed, May 31, 2006 at 09:55:31AM -0600, Stephen John Smoogen wrote: > >> The clock should not advance faster than real time. The issues where I > >> have seen this happen, the system needed either a new motherboard or > > > > problems may happen too if you are using some kind of CPU frequency > > scaling - are you? > > Also, is this an SMP kernel by any chance? I've just spent several > days trying to fix a similar problem with a 4.3 SMP installation. > The clock would run correctly when booted into non-SMP kernel. It would > also run correctly if I rebooted it once I had observed it running > fast. If the machine was coldstarted once more then the problem would > re-occur - very strange behaviour! I think I've got it controlled now > by adding 'noapic' to the kernel parameters. I did quite a bit of > googling whilst trying to work out what was wrong and it seems there is > a bug with SMP kernels which should be fixed in 2.6.14 if I remember > correctly. However, if you're not running an SMP kernel then this is > all irrelevant so I'll shut up! > hI in most cases, noapic is a sledgehammer that is trying to fix a small job. I would look for a BIOS update (as most of these clock issues end up something that the microcode can fix) or I would try Troy Dawsons suggestions of "enable_timer_pin_1" also, there is the opposite option: "disable_timer_pin_1" > -- > Mark Whidby > Faculty of Engineering and Physical Sciences > -- Stephen J Smoogen. CSIRT/Linux System Administrator