Sender: |
|
Date: |
Thu, 1 Jun 2006 08:43:29 -0600 |
MIME-version: |
1.0 |
Reply-To: |
|
Content-type: |
text/plain; format=flowed; charset=ISO-8859-1 |
Subject: |
|
From: |
|
Content-disposition: |
inline |
In-Reply-To: |
|
Content-transfer-encoding: |
7BIT |
Comments: |
|
Parts/Attachments: |
|
|
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
|
|
|