SCIENTIFIC-LINUX-USERS Archives

June 2006

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailling list for Scientific Linux users worldwide <[log in to unmask]>
Date:
Thu, 1 Jun 2006 09:16:20 +0100
MIME-version:
1.0
Reply-To:
Mark Whidby <[log in to unmask]>
Content-type:
text/plain; format=flowed; charset=ISO-8859-1
Subject:
From:
Mark Whidby <[log in to unmask]>
In-Reply-To:
Content-transfer-encoding:
7BIT
Comments:
Parts/Attachments:
text/plain (24 lines)
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!

-- 
Mark Whidby
Faculty of Engineering and Physical Sciences

ATOM RSS1 RSS2