Re: [gentoo-amd64] Re: kernel config file for A8N-SLI Premium

[Steve Herber]

Thanks Duncan.

I am doing all the things you mentioned.  But because you spent some
time to help me I realized I should do a bit more work.  I checked
bugzilla and discovered this:

http://bugs.gentoo.org/show_bug.cgi?id=105978

Commenting out /etc/conf.d/ntpd.conf -u ntp:ntp and now it works.

Can't wait for that bug to get fixed.

Now if I could just get a new kernel to boot.

Thanks!

Steve Herber	herber@×××××.com		work: 206-221-7262
Security Engineer, UW Medicine, IT Services	home: 425-454-2399

On Tue, 14 Mar 2006, Duncan wrote:

> Steve Herber posted <Pine.LNX.4.64.0603140110330.17364@×××××.com>,
> excerpted below,  on Tue, 14 Mar 2006 01:26:10 -0800:
>
>> I have a nice new A8N-SLI Premium system and I have two problems with it.
>> The second problem I have is that ntpd fails with the error:
>>
>> Mar 13 08:41:54 fester ntpd[16778]: ntpd 4.2.0a@1.1191-r Thu Feb 23
>> 17:17:02 PST 2006 (1)
>> Mar 13 08:41:54 fester ntpd[16778]: precision = 1.000 usec
>> Mar 13 08:41:54 fester ntpd[16778]: Listening on interface wildcard,
>> 0.0.0.0#123Mar 13 08:41:54 fester ntpd[16778]: Listening on interface lo,
>> 127.0.0.1#123
>> Mar 13 08:41:54 fester ntpd[16778]: Listening on interface eth1,
>> 192.168.168.6#123
>> Mar 13 08:41:54 fester ntpd[16778]: kernel time sync status 0040
>
> A search of the ntp documentation (in /usr/doc/ntp-<ver>/html/*) for sync
> status returns the error docs page.  It refers to timex.h from the ntp
> sources tarball.  You probably have that tarball in your portage distdir.
> A quick look here at the file... exerpted:
>
> /*
> * Status codes (timex.status)
> */
> [snip]
> #define STA_INS         0x0010  /* insert leap (rw) */
> #define STA_DEL         0x0020  /* delete leap (rw) */
> #define STA_UNSYNC      0x0040  /* clock unsynchronized (rw) */
> #define STA_FREQHOLD    0x0080  /* hold frequency (rw) */
>
> So... that would appear to simply say status unsynchronized.  Not a
> problem as that's the way it's supposed to start.  In fact, I figured
> that's what it meant, as mine always starts that way, but the status
> changes, later.
>
> Thus, either ntpd isn't failing after all, but still running and will
> eventually sync, or if it's failing, the log as posted doesn't reveal why.
>
> A couple suggestions.
>
> 1:  Check your timezone info.  If you have your clock set to local time
> but the timezone is set to UTC, assuming you aren't /at/ UTC local time,
> you'll be off by several hours and ntpd will normally refuse to touch the
> clock untl you set it to something closer to what ntpd can grok.
>
> 2:  It's always best to run ntp-client as well as ntpd.  The init ordering
> will order ntp-client before ntpd if they are both in the same initlevel,
> which is what you want.  ntp-client does a quick-check and approximate
> sync, stepping the clock as necessary to get it /close/ to the right time.
> It is, however, a one-shot deal.  ntpd then takes over and makes fine
> adjustments as necessary to sync the clock more closely, then tracks it to
> ensure it stays synced.  By running ntp-client first, you ensure the clock
> is close enough to correct that ntpd shouldn't protest.  It will still
> start as status 0040, but will sync up, usually within 15 minutes or so.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
>
>
> --
> gentoo-amd64@g.o mailing list
>
-- 
gentoo-amd64@g.o mailing list