Greetings everybody;
I seem to have an ntp problem. I noticed a few minutes ago that if
my watch was anywhere near correct, then the computer was about 6
minutes fast. Doing a service ntpd restart crash set it back nearly
6 minutes.
Kernel is 2.6.15-rc5, xp2800 athlon box, gig of ram.
Heres the log since yesterdays reboot, including the restart just
now. What can be learned from it?
4 Dec 10:39:16 ntpd[1981]: logging to file /var/log/ntp.log
4 Dec 10:39:16 ntpd[1981]: ntpd [email protected] Fri Aug 26 04:27:20
EDT 2005 (1)
4 Dec 10:39:16 ntpd[1981]: precision = 1.000 usec
4 Dec 10:39:16 ntpd[1981]: Listening on interface wildcard,
0.0.0.0#123
4 Dec 10:39:16 ntpd[1981]: Listening on interface lo, 127.0.0.1#123
4 Dec 10:39:16 ntpd[1981]: Listening on interface eth0,
192.168.71.3#123
4 Dec 10:39:16 ntpd[1981]: kernel time sync status 0040
4 Dec 10:39:17 ntpd[1981]: frequency initialized 4.392 PPM from
/var/lib/ntp/drift
4 Dec 10:42:32 ntpd[1981]: synchronized to LOCAL(0), stratum 10
4 Dec 10:42:32 ntpd[1981]: kernel time sync disabled 0041
4 Dec 10:43:36 ntpd[1981]: kernel time sync enabled 0001
4 Dec 14:30:12 ntpd[1981]: synchronized to 80.96.120.249, stratum 2
4 Dec 14:33:02 ntpd[1981]: synchronized to 64.109.43.141, stratum 2
4 Dec 14:35:12 ntpd[1981]: synchronized to LOCAL(0), stratum 10
4 Dec 20:35:32 ntpd[1981]: synchronized to 80.96.120.249, stratum 2
4 Dec 20:37:40 ntpd[1981]: synchronized to 64.109.43.141, stratum 2
4 Dec 20:38:56 ntpd[1981]: synchronized to LOCAL(0), stratum 10
5 Dec 00:06:20 ntpd[1981]: ntpd exiting on signal 15
5 Dec 00:00:38 ntpd[22610]: logging to file /var/log/ntp.log
5 Dec 00:00:38 ntpd[22610]: ntpd [email protected] Fri Aug 26 04:27:20
EDT 2005 (1)
5 Dec 00:00:38 ntpd[22610]: precision = 1.000 usec
5 Dec 00:00:38 ntpd[22610]: Listening on interface wildcard,
0.0.0.0#123
5 Dec 00:00:38 ntpd[22610]: Listening on interface lo, 127.0.0.1#123
5 Dec 00:00:38 ntpd[22610]: Listening on interface eth0,
192.168.71.3#123
5 Dec 00:00:38 ntpd[22610]: kernel time sync status 0040
5 Dec 00:00:39 ntpd[22610]: frequency initialized 4.392 PPM from
/var/lib/ntp/drift
5 Dec 00:03:58 ntpd[22610]: synchronized to LOCAL(0), stratum 10
5 Dec 00:03:58 ntpd[22610]: kernel time sync disabled 0041
5 Dec 00:05:04 ntpd[22610]: kernel time sync enabled 0001
Thanks for any hints anybody can throw my way.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
> Greetings everybody;
>
> I seem to have an ntp problem. I noticed a few minutes ago that if
> my watch was anywhere near correct, then the computer was about 6
> minutes fast. Doing a service ntpd restart crash set it back nearly
> 6 minutes.
Not sure exactly what is going on, but you might want to try dropping
the LOCAL server reference in your ntp.conf. It could be you're just
syncing w/ yourself.
thanks
-john
On Monday 05 December 2005 16:39, john stultz wrote:
>On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
>> Greetings everybody;
>>
>> I seem to have an ntp problem. I noticed a few minutes ago that if
>> my watch was anywhere near correct, then the computer was about 6
>> minutes fast. Doing a service ntpd restart crash set it back nearly
>> 6 minutes.
>
>Not sure exactly what is going on, but you might want to try dropping
>the LOCAL server reference in your ntp.conf. It could be you're just
>syncing w/ yourself.
>
>thanks
>-john
Joanne, bless her, pointed out that I had probably turned the ACPI
stuff in my kernel back on. She was of course correct, shut it off &
ntpd works just fine.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
> On Monday 05 December 2005 16:39, john stultz wrote:
> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
> >> Greetings everybody;
> >>
> >> I seem to have an ntp problem. I noticed a few minutes ago that if
> >> my watch was anywhere near correct, then the computer was about 6
> >> minutes fast. Doing a service ntpd restart crash set it back nearly
> >> 6 minutes.
> >
> >Not sure exactly what is going on, but you might want to try dropping
> >the LOCAL server reference in your ntp.conf. It could be you're just
> >syncing w/ yourself.
> >
> Joanne, bless her, pointed out that I had probably turned the ACPI
> stuff in my kernel back on. She was of course correct, shut it off &
> ntpd works just fine.
Err. ACPI stuff? Could you elaborate? Sounds like you have some sort of
bug hiding there.
thanks
-john
On Monday 05 December 2005 19:14, john stultz wrote:
>On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
>> On Monday 05 December 2005 16:39, john stultz wrote:
>> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
>> >> Greetings everybody;
>> >>
>> >> I seem to have an ntp problem. I noticed a few minutes ago that
>> >> if my watch was anywhere near correct, then the computer was about
>> >> 6 minutes fast. Doing a service ntpd restart crash set it back
>> >> nearly 6 minutes.
>> >
>> >Not sure exactly what is going on, but you might want to try
>> > dropping the LOCAL server reference in your ntp.conf. It could be
>> > you're just syncing w/ yourself.
>>
>> Joanne, bless her, pointed out that I had probably turned the ACPI
>> stuff in my kernel back on. She was of course correct, shut it off &
>> ntpd works just fine.
>
>Err. ACPI stuff? Could you elaborate? Sounds like you have some sort of
>bug hiding there.
This has been a relatively long standing problem, John. I think its
possibly related to some access path in the nforce2 chipset as it seems
to plague that chipset worse than others. But its long been, and I had
forgotten, that if ntpd didn't work, turning off the ACPI stuff was the
fix.
It had worked for a few kernel.org kernels and I had become complacent.
My mistake.
OTOH, calling it a local bug, no, I certainly wouldn't call it a local to
my machine bug. Jdow OTOH, running an FC4 box, has it enabled, and hers
is working just fine. She is I believe, running the FC4's latest kernel
too, so maybe the redhat people have massaged it. However, at one time
several months ago I believe she also had to have a grub argument
turning acpi=no.
There was a bunch of ntp related patches submitted recently, and I have
no idea which of them may have restored the broken acpi vs ntp scenario
to its formerly broken status, again.
Should it be looked at? Certainly, but I don't have the knowledge to do
so. So I build kernels, and report problems areas. The canary in the
coal mine so to speak. :-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Mon, 2005-12-05 at 21:07 -0500, Gene Heskett wrote:
> On Monday 05 December 2005 19:14, john stultz wrote:
> >On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
> >> On Monday 05 December 2005 16:39, john stultz wrote:
> >> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
> >> >> Greetings everybody;
> >> >>
> >> >> I seem to have an ntp problem. I noticed a few minutes ago that
> >> >> if my watch was anywhere near correct, then the computer was about
> >> >> 6 minutes fast. Doing a service ntpd restart crash set it back
> >> >> nearly 6 minutes.
> >> >
> >> >Not sure exactly what is going on, but you might want to try
> >> > dropping the LOCAL server reference in your ntp.conf. It could be
> >> > you're just syncing w/ yourself.
> >>
> >> Joanne, bless her, pointed out that I had probably turned the ACPI
> >> stuff in my kernel back on. She was of course correct, shut it off &
> >> ntpd works just fine.
> >
> >Err. ACPI stuff? Could you elaborate? Sounds like you have some sort of
> >bug hiding there.
>
> This has been a relatively long standing problem, John. I think its
> possibly related to some access path in the nforce2 chipset as it seems
> to plague that chipset worse than others. But its long been, and I had
> forgotten, that if ntpd didn't work, turning off the ACPI stuff was the
> fix.
Hey Gene,
I know we've spoken before about a few timekeeping problems, but
sometimes I have a hard time keeping all the issues straight. Have you
filed a bug on this issue? I queried for your email in
bugzilla.kernel.org and I couldn't find anything. If not, would you mind
opening a bug describing the behavior you are seeing with the different
boot options (possibly also dmesg output for both configurations)? It
will greatly help make sure this doesn't slip by without notice.
> It had worked for a few kernel.org kernels and I had become complacent.
> My mistake.
>
> OTOH, calling it a local bug, no, I certainly wouldn't call it a local to
> my machine bug. Jdow OTOH, running an FC4 box, has it enabled, and hers
> is working just fine. She is I believe, running the FC4's latest kernel
> too, so maybe the redhat people have massaged it. However, at one time
> several months ago I believe she also had to have a grub argument
> turning acpi=no.
Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
why it would have changed recently. Can you bound at all the kernel
versions where it worked and where it broke? Additionally, do be sure
you have the most recent BIOS, I've seen a number of nforce2 issues be
resolved with a BIOS update.
> There was a bunch of ntp related patches submitted recently, and I have
> no idea which of them may have restored the broken acpi vs ntp scenario
> to its formerly broken status, again.
I don't think the NTP changes would have triggered this, but I want to
be sure (its more likely something else in the timekeeping code is
causing problems).
> Should it be looked at? Certainly, but I don't have the knowledge to do
> so. So I build kernels, and report problems areas. The canary in the
> coal mine so to speak. :-)
The testing and problem report is very much appreciated! Start with
filing a bugzilla bug and then I'll point you at a few more mines to
checkout :)
thanks
-john
On Monday 05 December 2005 22:20, john stultz wrote:
>On Mon, 2005-12-05 at 21:07 -0500, Gene Heskett wrote:
>> On Monday 05 December 2005 19:14, john stultz wrote:
>> >On Mon, 2005-12-05 at 18:33 -0500, Gene Heskett wrote:
>> >> On Monday 05 December 2005 16:39, john stultz wrote:
>> >> >On Mon, 2005-12-05 at 00:31 -0500, Gene Heskett wrote:
>> >> >> Greetings everybody;
>> >> >>
>> >> >> I seem to have an ntp problem. I noticed a few minutes ago
>> >> >> that if my watch was anywhere near correct, then the computer
>> >> >> was about 6 minutes fast. Doing a service ntpd restart crash
>> >> >> set it back nearly 6 minutes.
>> >> >
>> >> >Not sure exactly what is going on, but you might want to try
>> >> > dropping the LOCAL server reference in your ntp.conf. It could
>> >> > be you're just syncing w/ yourself.
>> >>
>> >> Joanne, bless her, pointed out that I had probably turned the ACPI
>> >> stuff in my kernel back on. She was of course correct, shut it
>> >> off & ntpd works just fine.
>> >
>> >Err. ACPI stuff? Could you elaborate? Sounds like you have some sort
>> > of bug hiding there.
>>
>> This has been a relatively long standing problem, John. I think its
>> possibly related to some access path in the nforce2 chipset as it
>> seems to plague that chipset worse than others. But its long been,
>> and I had forgotten, that if ntpd didn't work, turning off the ACPI
>> stuff was the fix.
>
>Hey Gene,
>
> I know we've spoken before about a few timekeeping problems, but
>sometimes I have a hard time keeping all the issues straight. Have you
>filed a bug on this issue? I queried for your email in
>bugzilla.kernel.org and I couldn't find anything. If not, would you
> mind opening a bug describing the behavior you are seeing with the
> different boot options (possibly also dmesg output for both
> configurations)? It will greatly help make sure this doesn't slip by
> without notice.
You're asking me to fight with bugzilla again John? I'm not THAT
masochistic.
When you have to lose your cool to get out of the search for duplicate
entries menu's, I call the software broken. Lifes too short to put up
with that, just let me file the friggin bug and let the software search
for similar ones. If there are, then it should email you for
clarification as to whether my bug is a dup, or a new one with different
triggering conditions. The present interface is a genuine PITA.
>> It had worked for a few kernel.org kernels and I had become
>> complacent. My mistake.
>>
>> OTOH, calling it a local bug, no, I certainly wouldn't call it a
>> local to my machine bug. Jdow OTOH, running an FC4 box, has it
>> enabled, and hers is working just fine. She is I believe, running
>> the FC4's latest kernel too, so maybe the redhat people have massaged
>> it. However, at one time several months ago I believe she also had
>> to have a grub argument turning acpi=no.
>
>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
>why it would have changed recently. Can you bound at all the kernel
>versions where it worked and where it broke? Additionally, do be sure
>you have the most recent BIOS, I've seen a number of nforce2 issues be
>resolved with a BIOS update.
I've already put more powerdown cycles (60 some) on my hard drives
fighting with the recent tv card problem, I'd like to get some uptime
in. All I know for sure is if I build 2.6.15-rc5 with acpi, ntpd
doesn't work. ntpdate does, but ntpd doesn't. And both dmesg and the
ntp.log (and -d's passed at launch time do not make it more verbose,
they just keep it from starting) are silent as to the diffs other than
the interrupt number shuffling in dmesg when its on. But I suspect it
may have started with 2.6.15-rc2, and I didn't build rc1. And I *think*
it worked as recently as 2.6.14.1 with it turned on. I've cleaned house
in /usr/src's so I don't have anything older. Sorry.
>> There was a bunch of ntp related patches submitted recently, and I
>> have no idea which of them may have restored the broken acpi vs ntp
>> scenario to its formerly broken status, again.
>
>I don't think the NTP changes would have triggered this, but I want to
>be sure (its more likely something else in the timekeeping code is
>causing problems).
>
>> Should it be looked at? Certainly, but I don't have the knowledge to
>> do so. So I build kernels, and report problems areas. The canary in
>> the coal mine so to speak. :-)
>
>The testing and problem report is very much appreciated! Start with
>filing a bugzilla bug and then I'll point you at a few more mines to
>checkout :)
Maybe next week when I have restored my patience, its been in short
supply lately over this tv card problem. Joanne (jdow) might be able to
furnish more co-oberating details as she sees more machines at earthlink
in a days work than I do in a year. I only have 3 here on my little
network, one rh7.3 box (firewall), this one, and a box in the shop that
runs my milling machine, so there is not at the moment, a sacrificial
lamb.
>thanks
>-john
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
From: "Gene Heskett" <[email protected]>
>>> Should it be looked at? Certainly, but I don't have the knowledge to
>>> do so. So I build kernels, and report problems areas. The canary in
>>> the coal mine so to speak. :-)
>>
>>The testing and problem report is very much appreciated! Start with
>>filing a bugzilla bug and then I'll point you at a few more mines to
>>checkout :)
>
> Maybe next week when I have restored my patience, its been in short
> supply lately over this tv card problem. Joanne (jdow) might be able to
> furnish more co-oberating details as she sees more machines at earthlink
> in a days work than I do in a year. I only have 3 here on my little
> network, one rh7.3 box (firewall), this one, and a box in the shop that
> runs my milling machine, so there is not at the moment, a sacrificial
> lamb.
No I don't. I've just used ntp for several years, back to when it was
xntp and a new thing to RedHat releases. I don't have anything to do
with Earthlink other than as a customer. I use Linux as the firewall
and mail service here as well as a general "let off steam" from doing
work on Windows that I can't do on Linux. (Matrox DigiSuite cards
feature heavily.)
{^_^} Joanne
Gene Heskett a ?crit :
>>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
>>why it would have changed recently. Can you bound at all the kernel
>>versions where it worked and where it broke? Additionally, do be sure
>>you have the most recent BIOS, I've seen a number of nforce2 issues be
>>resolved with a BIOS update.
>
>
> I've already put more powerdown cycles (60 some) on my hard drives
> fighting with the recent tv card problem, I'd like to get some uptime
> in. All I know for sure is if I build 2.6.15-rc5 with acpi, ntpd
> doesn't work. ntpdate does, but ntpd doesn't. And both dmesg and the
> ntp.log (and -d's passed at launch time do not make it more verbose,
> they just keep it from starting) are silent as to the diffs other than
> the interrupt number shuffling in dmesg when its on. But I suspect it
> may have started with 2.6.15-rc2, and I didn't build rc1. And I *think*
> it worked as recently as 2.6.14.1 with it turned on. I've cleaned house
> in /usr/src's so I don't have anything older. Sorry.
I have to agree with John Stultz. I am one with a nForce2 chipset where
updating to the latest BIOS have totaly solved the excatly same ntpd
problem.
Regards,
--
Jean-Christian de Rivaz
On Tuesday 06 December 2005 02:33, jdow wrote:
>From: "Gene Heskett" <[email protected]>
>
>>>> Should it be looked at? Certainly, but I don't have the knowledge
>>>> to do so. So I build kernels, and report problems areas. The
>>>> canary in the coal mine so to speak. :-)
>>>
>>>The testing and problem report is very much appreciated! Start with
>>>filing a bugzilla bug and then I'll point you at a few more mines to
>>>checkout :)
>>
>> Maybe next week when I have restored my patience, its been in short
>> supply lately over this tv card problem. Joanne (jdow) might be able
>> to furnish more co-oberating details as she sees more machines at
>> earthlink in a days work than I do in a year. I only have 3 here on
>> my little network, one rh7.3 box (firewall), this one, and a box in
>> the shop that runs my milling machine, so there is not at the moment,
>> a sacrificial lamb.
>
>No I don't. I've just used ntp for several years, back to when it was
>xntp and a new thing to RedHat releases. I don't have anything to do
>with Earthlink other than as a customer. I use Linux as the firewall
>and mail service here as well as a general "let off steam" from doing
>work on Windows that I can't do on Linux. (Matrox DigiSuite cards
>feature heavily.)
>
>{^_^} Joanne
My mistaken impression then, and my apologies Joanne. I was under the
impression that you've been an earthlink related employee for several
years, and just speaking as a user for those posts that were revelant.
Does this mean I should go buy a Matrox card the next time I need a video
card?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Tuesday 06 December 2005 06:44, Jean-Christian de Rivaz wrote:
>Gene Heskett a ?crit :
>>>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not
>>> sure why it would have changed recently. Can you bound at all the
>>> kernel versions where it worked and where it broke? Additionally, do
>>> be sure you have the most recent BIOS, I've seen a number of nforce2
>>> issues be resolved with a BIOS update.
>>
>> I've already put more powerdown cycles (60 some) on my hard drives
>> fighting with the recent tv card problem, I'd like to get some uptime
>> in. All I know for sure is if I build 2.6.15-rc5 with acpi, ntpd
>> doesn't work. ntpdate does, but ntpd doesn't. And both dmesg and
>> the ntp.log (and -d's passed at launch time do not make it more
>> verbose, they just keep it from starting) are silent as to the diffs
>> other than the interrupt number shuffling in dmesg when its on. But
>> I suspect it may have started with 2.6.15-rc2, and I didn't build
>> rc1. And I *think* it worked as recently as 2.6.14.1 with it turned
>> on. I've cleaned house in /usr/src's so I don't have anything older.
>> Sorry.
>
>I have to agree with John Stultz. I am one with a nForce2 chipset where
>updating to the latest BIOS have totaly solved the excatly same ntpd
>problem.
Problems: I went and got a newer bios, for a Biostar N7NCD-Pro, put it
on a floppy and rebooted. Going into the bios I chose to update it as
that is part of the existing bios, no awardflash.exe needed according to
the propaganda. But the bios can't find it on the floppy.
Or do I still need awardflash.exe on the floppy too? I'll put it there
and try again.
------
Several reboots later, I still haven't managed to get it updated.
The first problem was that the builtin bios flasher couldn't find the
file on the floppy, presumably because while vfat shows the correct name
of ncdp1102bf.exe, a dos boot or compatible dir util can't see it as
anything but ncdp11~1.exe. So I put their latest awdflash.exe on the
disk too. Same deal except I had it save the old bios as oldbios.exe,
and it can see that, but not the new file until I renamed it to
something short enough for an idiot dos, ncdpbf.exe.
So, having arrived as a dos compatible name, I tried again, but now its
bitching about a file size error and still refuses to do the update
using their instructions to recover a bad update. And the builtin bios
flasher still can't see the shortened name. I don't see a filesize
error in the ls -l's below either.
An ls -l on that floppy shows:
[root@coyote root]# ls -l /mnt/floppy
total 563
-rwxr-xr-x 1 root root 47916 Dec 6 13:23 awdflash.exe
-rwxr-xr-x 1 root root 266240 Dec 6 13:24 ncdpbf.exe
-rwxr-xr-x 1 root root 262144 Dec 6 2005 oldbios.exe
An ls -l on the /dos dir of my hd, grepped for ncdp:
-rwxr-xr-x 1 root root 266240 Sep 16 2004 ncdp0730bf.exe
-rwxr-xr-x 1 root root 266240 Dec 6 12:10 ncdp1102bf.exe
The ncdp0730bf.exe is the file thats in the bios now, and which was then
saved using the awdflash.exe as oldbios.exe thats on that disk now.
FWIW, awdflash.exe CAN see the oldbios.exe file just fine. I have now
downloaded the new one twice from biostar.com.tw.
Has anyone got a clue as to what the heck is wrong here?
>Regards,
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Tuesday 06 December 2005 14:02, Gene Heskett wrote:
>On Tuesday 06 December 2005 06:44, Jean-Christian de Rivaz wrote:
>>Gene Heskett a ?crit :
>>>>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not
>>>> sure why it would have changed recently. Can you bound at all the
>>>> kernel versions where it worked and where it broke? Additionally,
>>>> do be sure you have the most recent BIOS, I've seen a number of
>>>> nforce2 issues be resolved with a BIOS update.
>>>
>>> I've already put more powerdown cycles (60 some) on my hard drives
>>> fighting with the recent tv card problem, I'd like to get some
>>> uptime in. All I know for sure is if I build 2.6.15-rc5 with acpi,
>>> ntpd doesn't work. ntpdate does, but ntpd doesn't. And both dmesg
>>> and the ntp.log (and -d's passed at launch time do not make it more
>>> verbose, they just keep it from starting) are silent as to the diffs
>>> other than the interrupt number shuffling in dmesg when its on. But
>>> I suspect it may have started with 2.6.15-rc2, and I didn't build
>>> rc1. And I *think* it worked as recently as 2.6.14.1 with it turned
>>> on. I've cleaned house in /usr/src's so I don't have anything
>>> older. Sorry.
>>
>>I have to agree with John Stultz. I am one with a nForce2 chipset
>> where updating to the latest BIOS have totaly solved the excatly same
>> ntpd problem.
>
>Problems: I went and got a newer bios, for a Biostar N7NCD-Pro, put it
>on a floppy and rebooted. Going into the bios I chose to update it as
>that is part of the existing bios, no awardflash.exe needed according
> to the propaganda. But the bios can't find it on the floppy.
>
>Or do I still need awardflash.exe on the floppy too? I'll put it there
>and try again.
>------
>Several reboots later, I still haven't managed to get it updated.
>
>The first problem was that the builtin bios flasher couldn't find the
>file on the floppy, presumably because while vfat shows the correct
> name of ncdp1102bf.exe, a dos boot or compatible dir util can't see it
> as anything but ncdp11~1.exe. So I put their latest awdflash.exe on
> the disk too. Same deal except I had it save the old bios as
> oldbios.exe, and it can see that, but not the new file until I renamed
> it to something short enough for an idiot dos, ncdpbf.exe.
>
>So, having arrived as a dos compatible name, I tried again, but now its
>bitching about a file size error and still refuses to do the update
>using their instructions to recover a bad update. And the builtin bios
>flasher still can't see the shortened name. I don't see a filesize
>error in the ls -l's below either.
>
>An ls -l on that floppy shows:
>[root@coyote root]# ls -l /mnt/floppy
>total 563
>-rwxr-xr-x 1 root root 47916 Dec 6 13:23 awdflash.exe
>-rwxr-xr-x 1 root root 266240 Dec 6 13:24 ncdpbf.exe
>-rwxr-xr-x 1 root root 262144 Dec 6 2005 oldbios.exe
>
>
>An ls -l on the /dos dir of my hd, grepped for ncdp:
>-rwxr-xr-x 1 root root 266240 Sep 16 2004 ncdp0730bf.exe
>-rwxr-xr-x 1 root root 266240 Dec 6 12:10 ncdp1102bf.exe
>
>The ncdp0730bf.exe is the file thats in the bios now, and which was
> then saved using the awdflash.exe as oldbios.exe thats on that disk
> now. FWIW, awdflash.exe CAN see the oldbios.exe file just fine. I
> have now downloaded the new one twice from biostar.com.tw.
>
>Has anyone got a clue as to what the heck is wrong here?
>
Well, it turns out I was the one without a clue, I was downloading the
bios images from biostar.com.tw, which are NOT apparently correct. On a
hunch, I specifically went to the usa1.biostar.com site, and found there
was a different file posted there for my M7NCD-pro board.
That one installed without any hiccups, but I saw where the sign-on said
it was DDR400 dual channel ram, whereas before the update it was DDR333
dual channel ram. As the XP2800 athlon isn't rated for DDR400, I backed
into the bios and reset the fsb for 166 mhz which should give me a 333
fsb. But it still says DDR400 at signon. So I guess we'll see if its
now stable at a 400 mhz fsb even if its set to 166/333.
dmesg says its running the cpu at 2080mhz, which is normal.
Has anyone else observed this and care to comment?
>>Regards,
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
From: "Gene Heskett" <[email protected]>
> On Tuesday 06 December 2005 02:33, jdow wrote:
>>From: "Gene Heskett" <[email protected]>
>>
>>>>> Should it be looked at? Certainly, but I don't have the knowledge
>>>>> to do so. So I build kernels, and report problems areas. The
>>>>> canary in the coal mine so to speak. :-)
>>>>
>>>>The testing and problem report is very much appreciated! Start with
>>>>filing a bugzilla bug and then I'll point you at a few more mines to
>>>>checkout :)
>>>
>>> Maybe next week when I have restored my patience, its been in short
>>> supply lately over this tv card problem. Joanne (jdow) might be able
>>> to furnish more co-oberating details as she sees more machines at
>>> earthlink in a days work than I do in a year. I only have 3 here on
>>> my little network, one rh7.3 box (firewall), this one, and a box in
>>> the shop that runs my milling machine, so there is not at the moment,
>>> a sacrificial lamb.
>>
>>No I don't. I've just used ntp for several years, back to when it was
>>xntp and a new thing to RedHat releases. I don't have anything to do
>>with Earthlink other than as a customer. I use Linux as the firewall
>>and mail service here as well as a general "let off steam" from doing
>>work on Windows that I can't do on Linux. (Matrox DigiSuite cards
>>feature heavily.)
>>
>>{^_^} Joanne
>
> My mistaken impression then, and my apologies Joanne. I was under the
> impression that you've been an earthlink related employee for several
> years, and just speaking as a user for those posts that were revelant.
>
> Does this mean I should go buy a Matrox card the next time I need a video
> card?
No, my competitors are not ATI and nVidia. And the cards I work with
are intended for broadcast video.
And this is severely OT by now so... Ta
{^_^}
On Monday 05 December 2005 22:20, john stultz wrote:
[...]
>Hmmm. Indeed the nforce2 has had a number of problems, but I'm not sure
>why it would have changed recently. Can you bound at all the kernel
>versions where it worked and where it broke? Additionally, do be sure
>you have the most recent BIOS, I've seen a number of nforce2 issues be
>resolved with a BIOS update.
And, while I had a heck of a time doing the bios upgrade, it did work,
acpi is now enabled, and ntpd is working 'nominally'.
Many thanks for the kick in the pants to go do that, John.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Dec 06, 2005, at 16:22, Gene Heskett wrote:
> That one installed without any hiccups, but I saw where the sign-on
> said it was DDR400 dual channel ram, whereas before the update it
> was DDR333 dual channel ram. As the XP2800 athlon isn't rated for
> DDR400, I backed into the bios and reset the fsb for 166 mhz which
> should give me a 333
> fsb. But it still says DDR400 at signon. So I guess we'll see if
> its now stable at a 400 mhz fsb even if its set to 166/333.
Hmm, this sounds a lot like the BIOS insanity we saw on one cheapo
Chaintech board. We knew it was bad when the thing reported in its
boot display that the CPU was an "Intel Athlon". Things only got
worse from there; but sadly there was no BIOS update, and we ended up
throwing away the $35 board just on general principles :-D.
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare
On Wednesday 07 December 2005 00:14, Kyle Moffett wrote:
>On Dec 06, 2005, at 16:22, Gene Heskett wrote:
>> That one installed without any hiccups, but I saw where the sign-on
>> said it was DDR400 dual channel ram, whereas before the update it
>> was DDR333 dual channel ram. As the XP2800 athlon isn't rated for
>> DDR400, I backed into the bios and reset the fsb for 166 mhz which
>> should give me a 333
>> fsb. But it still says DDR400 at signon. So I guess we'll see if
>> its now stable at a 400 mhz fsb even if its set to 166/333.
>
>Hmm, this sounds a lot like the BIOS insanity we saw on one cheapo
>Chaintech board. We knew it was bad when the thing reported in its
>boot display that the CPU was an "Intel Athlon". Things only got
>worse from there; but sadly there was no BIOS update, and we ended up
>throwing away the $35 board just on general principles :-D.
>
Thats been my impression of anything wearing a chaintech label, and I
cannot pin a reason on it, just 71 years of experience. Is that good
enough? Dunno Kyle, but when shopping for a mobo, the chaintech stuff
has always been bypassed. Some of the tech reports seem to say they're
ok though. Another example of YMMV I guess.
Anyway, I did finally get the bios to stop running the memory faster than
an XP2800, rated at DDR333 can do. So after a couple of hard crashes,
it seems to be back among the living. I had to use the expert group of
settings though, & me not an expert, not 50 miles from home, nor am I
carrying a briefcase as I once heard an expert described.
And, acpi is on, and ntpd is happy with the new bios. Hurrah!
>Cheers,
>Kyle Moffett
>
>--
>There are two ways of constructing a software design. One way is to
>make it so simple that there are obviously no deficiencies. And the
>other way is to make it so complicated that there are no obvious
>deficiencies. The first method is far more difficult.
> -- C.A.R. Hoare
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett a ?crit :
> And, acpi is on, and ntpd is happy with the new bios. Hurrah!
Good news!
I wonder if it would be a good idea to add something into the kernel or
into ntpd to alert the users that ntpd can't run normaly because of a
too fast drift ? Then a BIOS upgrade could be proposed (especially on a
nForce2 system). I don't know if it's even realistc.
Regards,
--
Jean-Christian de Rivaz
On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>Gene Heskett a ?crit :
>> And, acpi is on, and ntpd is happy with the new bios. Hurrah!
>
>Good news!
>
>I wonder if it would be a good idea to add something into the kernel or
>into ntpd to alert the users that ntpd can't run normaly because of a
>too fast drift ? Then a BIOS upgrade could be proposed (especially on a
>nForce2 system). I don't know if it's even realistc.
>
>Regards,
The drift itself wasn't what I'd call excessive,
something like 6 minutes in a week, which for
mainboard quality crystals is pretty darned good.
I didn't discover it wasn't working till my watch beeped
at me on the hour like it always does (casio) and I glanced
at the cornerclock to see it said it was 6 minutes & some
after the hour. So either my watch was funkity, or the ntpd.
My watch has been *very* reliable, staying within 10 seconds
a month, so I discounted that theory and went after ntpd.
After my experience, I'd recommend any nforce2 board get
the latest bios and install it. On this biostar though,
I then had to go into the expert mode on the 3rd screen
and play for a while till I had restored the DDR to 333 mhz,
the defaults want to run it at 400 mhz, and an XP2800
athlon will only stay up 10 minutes or so at 40, as its
only rated at 333. The faster athlons, Xp3200+ chips,
are rated for 400 though.
But in my case, I think that was the only 'gotcha', and
everything else seems to be as happy as that infamous pig
in you know what.
When its running, drift file contents have not to my knowledge ever
exceeded 6.000, and are currently running like this:
drift=4.236
remote refid st t when poll reach delay offset jitter
==============================================================================
+ns2.pulsation.f 129.240.64.3 3 u 232 1024 377 132.270 1.516 1.117
+ntp.aramiska.ne 172.16.33.1 2 u 333 1024 377 123.445 3.725 0.704
*ftp.cerias.purd 128.10.252.7 2 u 1370 1024 376 73.101 0.532 5.700
LOCAL(0) LOCAL(0) 10 l 6 64 377 0.000 0.000 0.001
drift=4.236
I have a while true script logging the drift and the output of
ntpq -p into /var/log/ntp.log every half hour temporarily.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett a ?crit :
> On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>
>>Gene Heskett a ?crit :
>>
>>>And, acpi is on, and ntpd is happy with the new bios. Hurrah!
>>
>>Good news!
>>
>>I wonder if it would be a good idea to add something into the kernel or
>>into ntpd to alert the users that ntpd can't run normaly because of a
>>too fast drift ? Then a BIOS upgrade could be proposed (especially on a
>>nForce2 system). I don't know if it's even realistc.
>>
>>Regards,
>
>
> The drift itself wasn't what I'd call excessive,
> something like 6 minutes in a week, which for
> mainboard quality crystals is pretty darned good.
ntpd work only on system with a drift of maximum +/-500ppm. This post
summarize a lot of informations about the problem:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113105244509795&w=2
It was found later that an issue into the nForce2 is the root of the
problem and that a BIOS update solve it.
6.0 / (60*24*7) * 1e6 = 595.24
6 minutes per week is near 600ppm, it's enough to trigg the problem you
have seen. Even very cheap crystal are 100ppm at commercial temperature
range. 100ppm is about 1 minute per week. Some crystal manufacturers
propose now 30ppm as the default standard at commercial temperature range.
As your watch prove, good cristal can be just a few ppm (about 3.86ppm
for your watch)
Regards,
--
Jean-Christian de Rivaz
On Wednesday 07 December 2005 18:34, Jean-Christian de Rivaz wrote:
>Gene Heskett a ?crit :
>> On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>>>Gene Heskett a ?crit :
>>>>And, acpi is on, and ntpd is happy with the new bios. Hurrah!
>>>
>>>Good news!
>>>
>>>I wonder if it would be a good idea to add something into the kernel
>>> or into ntpd to alert the users that ntpd can't run normaly because
>>> of a too fast drift ? Then a BIOS upgrade could be proposed
>>> (especially on a nForce2 system). I don't know if it's even
>>> realistc.
>>>
>>>Regards,
>>
>> The drift itself wasn't what I'd call excessive,
>> something like 6 minutes in a week, which for
>> mainboard quality crystals is pretty darned good.
>
>ntpd work only on system with a drift of maximum +/-500ppm. This post
>summarize a lot of informations about the problem:
>http://marc.theaimsgroup.com/?l=linux-kernel&m=113105244509795&w=2
>It was found later that an issue into the nForce2 is the root of the
>problem and that a BIOS update solve it.
>
Yes, but this 500ppm limitation does not AIUI, include the mitigating
effects of the drift files contents I'm told. I know there have been
times when I had to manually play with it to get it in range, or simply
delete it and let ntpd reset it, which it then finetuned as I can see in
an ntpq -p output.
Is this incorrect? FWIW, the value in the drift file right now is within
about 1 ppm of the value that was in it when it wasn't working. So that
tells me the drift rate was ok, with the files compensating effects
added in. Offsets to the server its peering to right now haven't
exceeded 6.554 since the last reboot. Humm, I'll take it back, just in
the last half hour the peer site has gone from an offset of -1.568 to an
offset of -41.184, and it did this without updateing the contents of the
drift file logged a few milliseconds before. This bears watching I
think.
>6.0 / (60*24*7) * 1e6 = 595.24
>6 minutes per week is near 600ppm, it's enough to trigg the problem you
>have seen. Even very cheap crystal are 100ppm at commercial temperature
>range. 100ppm is about 1 minute per week. Some crystal manufacturers
>propose now 30ppm as the default standard at commercial temperature
> range.
>
>As your watch prove, good cristal can be just a few ppm (about 3.86ppm
>for your watch)
>
>Regards,
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Wednesday 07 December 2005 16:56, Jean-Christian de Rivaz wrote:
>Gene Heskett a ?crit :
>> And, acpi is on, and ntpd is happy with the new bios. Hurrah!
>
>Good news!
>
>I wonder if it would be a good idea to add something into the kernel
> or into ntpd to alert the users that ntpd can't run normaly because
> of a too fast drift ? Then a BIOS upgrade could be proposed
> (especially on a nForce2 system). I don't know if it's even
> realistc.
>
>Regards,
I don't know as this is a kernel issue in this case. So if warning are
to be output to the logs, then they really should come from ntpd IMO.
Frankly, the existing log output from ntpd sucks. Once it has output a
msg saying:
8 Dec 16:38:20 ntpd[1966]: kernel time sync enabled 0001
it is totally mute until:
11 Dec 10:47:29 ntpd[1966]: synchronized to 64.112.189.11, stratum 2
11 Dec 13:04:34 ntpd[1966]: synchronized to 80.96.123.120, stratum 2
Nearly 3 days of silence, during which time it updated the contents of
the drift file at least 20 times is rather hard to swallow when you
are trying to see what its doing. So I have another script being
started in /etc/init/ntpd that fires off at 30 minute intervals, cats
the contents of the drift file to the log & runs an instance of ntpq
-p >>ntp.log.
That looks like this (excuse the word wrap please):
drift=4.353
remote refid st t when poll reach delay offset
jitter
==============================================================================
+time.uswo.net 128.10.252.6 2 u 126 1024 377 85.553 -1.657
0.167
+rrcs-24-172-8-1 80.64.135.105 3 u 200 1024 377 73.522 6.885
3.648
*ecoca.eed.usv.r 80.96.120.253 2 u 200 1024 377 206.528 2.798
3.468
LOCAL(0) LOCAL(0) 10 l 39 64 377 0.000 0.000
0.001
A bit voluminous perhaps, but it sure gives me a much better picture of
whether I can set my $25 Casio wristwatch to somewhere near the real
time. And, now that I've determined it is working, I could shut it
off, but what happens then when I reboot to a new kernel and foo, bar,
and baz are all on the missing list as has happened several times? So
I'll leave it running until I feel I can realy trust it.
I guess my point is, if we are to have a time synchronizer utility, it
either should work, or raise hell & stomp its feet all over the logs
once it determines that it cannot work correctly. ntpd as implemented
right now has a very bad case of laringitis(sp).
--
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <[email protected]> which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.