I have had a similar problem with mobos in the past.
A gigabyte board as I remember.
fixed it by replacing the battery.
Cheers Chris T
= = = Original message = = =
Disappointingly the clock is back to drifting again, so a cron job every
10 minutes it is . . .
The board in question is an Asus M2N
I'm reliably informed that clock drift problems with NVIDIA nForce
chip-sets are fixed in the Ubuntu distribution.
On 9/24/07, Roger Searle <[EMAIL PROTECTED]> wrote:
> Disappointingly the clock is back to drifting again, so a cron job every
> 10 minutes it is . . .
>
> The board in question is a
Disappointingly the clock is back to drifting again, so a cron job every
10 minutes it is . . .
The board in question is an Asus M2N which has been fine in all other
regards.
Roger
Roger Searle wrote:
I'm pleased to report that time on that box is no longer drifting. So
I won't need to im
> Whopee! I ended up with custom kernels, weird boot parameters and allsorts
> to get mine working. In the end, I think it was a kernel update that fixed
> it. Just a poor choice of motherboard I on my part I think.
And the mobo make and model yadda yadda is?
To save us the same grief.
Volke
Steve Holdoway wrote:
If that is the case then I expect that you'll find that there's a call to
ntpdate in the start section of /etc/init.d/ntp, as this functionality is *not*
a part of the ntp daemon.
Yes there are. So now I can make sense of the apparently conflicting
replies from you an
Ooh! A hijack!
The "3Gb barrier" was discussed at Dan's Data:
http://www.dansdata.com/askdan00015.htm
I only skimmed the article, but it might shed some light on the issue.
A
On Wed, September 19, 2007 10:04, Carl Cerecke wrote:
> Hi Steve,
>
>
> What was the symptoms with > 3G memory? Did th
64 bit kernel - to the best of my understanding, a lot of the device drivers (
well, graphics ards at least ) map their own physical memory to the area just
above the 32 bit limit, and when the kernel tries to access it too
I'm sure someone will have a more exact description of what's happen
Hi Steve,
What was the symptoms with > 3G memory? Did the crashes happen on boot
up? Or randomly?
I ask because I have a machine here (dual-core Intel, 4GB mem) that
has occasional hard freezes (all frozen. No kbd or even ping
response). I thought it might be the nvidia driver (using the latest
On Wed, 19 Sep 2007 12:24:57 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
> Steve Holdoway wrote:
> > On Wed, 19 Sep 2007 11:27:47 +1200
> > Roger Searle <[EMAIL PROTECTED]> wrote:
> >
> >
> >> I'm pleased to report that time on that box is no longer drifting. So I
> >> won't need to implement o
Steve Holdoway wrote:
On Wed, 19 Sep 2007 11:27:47 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
I'm pleased to report that time on that box is no longer drifting. So I
won't need to implement one of these options, and will give some thought
to the "no" answer to point 1.
Thanks to everyon
On Wed, 19 Sep 2007 11:27:47 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
> I'm pleased to report that time on that box is no longer drifting. So I
> won't need to implement one of these options, and will give some thought
> to the "no" answer to point 1.
>
> Thanks to everyone for their replies
I'm pleased to report that time on that box is no longer drifting. So I
won't need to implement one of these options, and will give some thought
to the "no" answer to point 1.
Thanks to everyone for their replies.
Roger
Steve Holdoway wrote:
On Wed, 19 Sep 2007 06:15:21 +1200
Roger Searle <
On Wed, 19 Sep 2007 06:15:21 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
> so 2 options seem to be valid:
>
> 1. if the drift is small enough between the frequent ntp restarts
> then"service ntp restart" will suffice.
No. This is still incorrect.
>
> 2. "service ntp stop && ntpdate ntp.massey
so 2 options seem to be valid:
1. if the drift is small enough between the frequent ntp restarts
then"service ntp restart" will suffice.
2. "service ntp stop && ntpdate ntp.massey.ac.nz && service ntp start"
will cover drifts beyond what ever the ntp maximum adjustment is.
Do I have my head
> Historically, ntpdate was run once as a part of the ntpd init script,
It still is, on SUSE anyway. You can't reliably start up ntpd without
running ntpdate (or the equivalent) first, so there's about as much
argument for leaving it in the ntpd script as there is for separating
it.
Volker
--
V
On Tue, 18 Sep 2007 12:48:38 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
> I'll see what date shows me tomorrow. Google tells me that some people
> have resolved this issue by appending "noapic acpi=off" to grub. If I
> am still getting nowhere then I believe having cron do "service ntp stop
>
Thanks to everyone for all the replies, very useful. I was unclear
about the difference between ntpdate and ntpd. Kernel version on the
problematic machine was up to date. I have altered the installation
source to include the nvidia drivers, checked for all updates, turned
off the IPCop box anno
On Mon, 17 Sep 2007, Roger Searle wrote:
> I could be missing something obvious, so would be interested in any
> suggestions from anyone about resolving this?
I had a batch of machines with something similar a few years back. The
problem was that the CPU fan went a different speeds according to th
On Mon 17 Sep 2007 16:41:06 NZST +1200, Robert Fisher wrote:
> I just use the KDE setup these days and it seems to work for me.
>
> Right click the KDE clock and select "adjust date and time"
>
> Tick "set time and date automatically" and choose a server
> (I use ntp.massey.ac.nz)
Hmmm.
Ok, th
On Mon 17 Sep 2007 15:40:29 NZST +1200, Roger Searle wrote:
> My potentially groundless assumption is that because the motherboard is
> new, that the battery is good.
Good assumption.
As that battery is only used to hold the time in the CMOS clock while
the computer is powered off, don't waste a
> Hi, I have a SuSE 64bit install on an Asus M2N motherboard, and I recall
> others having (unresolvable?) time drift issues with a 64bit
> installation.
Those problems were solved some time ago. The issue was something to do
with kernel timekeeping and certain versions of AMD 64bit CPUs
On Mon, 17 Sep 2007 16:41:06 +1200
Robert Fisher <[EMAIL PROTECTED]> wrote:
> On Monday 17 September 2007 12:48 pm, Roger Searle wrote:
>
> >
> > I could be missing something obvious, so would be interested in any
> > suggestions from anyone about resolving this?
>
> I just use the KDE setup the
On Monday 17 September 2007 12:48 pm, Roger Searle wrote:
>
> I could be missing something obvious, so would be interested in any
> suggestions from anyone about resolving this?
I just use the KDE setup these days and it seems to work for me.
Right click the KDE clock and select "adjust date and
id, 10.2.1.1 is the IPCop box. Also, there had been one
>> or more ntp restarts on the 11th and 12th. Strange that there are no
>> log entries over the weekend, uptime is 18 days.
>>
>> Roger Searle wrote:
>>
>>> Hi, I have a SuSE 64bit install on an Asus M
board, and I recall
> > others having (unresolvable?) time drift issues with a 64bit
> > installation. Perhaps the common factor was nvidia chipsets, but I could
> > be making that up. It is losing something like an hour a day.
> >
> > ntpd is running and getting time from an IPCop
others having (unresolvable?) time drift issues with a 64bit
> installation. Perhaps the common factor was nvidia chipsets, but I could
> be making that up. It is losing something like an hour a day.
>
> ntpd is running and getting time from an IPCop box. Yet the time
> reported by
Hi, I have a SuSE 64bit install on an Asus M2N motherboard, and I recall
others having (unresolvable?) time drift issues with a 64bit
installation. Perhaps the common factor was nvidia chipsets, but I could
be making that up. It is losing something like an hour a day.
ntpd is running and getting
27 matches
Mail list logo
