Johnny Hughes wrote:
Just for the record ... we had already taken action on that one to try
and get a bug corrected upstream (pretty good for someone who "Doesn't
know what is to give something back" ... sorry different thread :) :
http://bugs.centos.org/view.php?id=1459
Thanks for all you do!
If ->*A*<- Robert implied the negativism above, it wasn't me.
No glitch in building, maybe a problem with the kernel and your
hardware ... we always have a kernel and a kernel-smp.
I've never been crazy about this m/b. For openers, there's the Adaptec
2940 card whose BIOS cannot be reached via <cntl-A> during POST, which
could be a problem if the card did anything other than drive a scanner
and a DAT drive.
There is also a new ntp in those updates.
Indeed. The behavior was so familiar that I tried the kernel first and
got lucky. The new ntp works fine with the old kernel.
With 2.6.9-42.0.2.EL ntpd is clearly in trouble:
[root@mavis ~]# ntpq
ntpq> pe
remote refid st t when poll reach delay offset
jitter
==============================================================================
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 16 u - 64 0 0.000 0.000
4000.00
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 1 u 42 64 177 66.814 -183.39
2210.68
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 1 u 42 64 177 62.124 -3012.7
1711.21
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 1 u 39 64 177 52.048 -1387.5
1354.81
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 34 64 177 27.800 -814.06
1739.73
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 38 64 177 43.541 -2526.2
1372.69
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 37 64 177 21.179 -3646.6
2201.41
xxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 32 64 177 55.460 -1441.6
1360.43
*LOCAL(0) LOCAL(0) 10 l 30 64 177 0.000 0.000
0.004
ntpq> q
[root@mavis ~]# uptime
09:00:07 up 9 min, 7 users, load average: 0.02, 0.33, 0.24
[root@mavis ~]# uname -a
Linux mavis.localdomain 2.6.9-42.0.2.EL #1 Tue Aug 22 23:56:05 CDT 2006
i686 athlon i386 GNU/Linux
[root@mavis ~]# rpm -q ntp
ntp-4.2.0.a.20040617-4.EL4.1
[root@mavis ~]#
With 2.6.9-34.0.2.EL, ntp has congratulated itself <5 minutes :
ntpq> pe
remote refid st t when poll reach delay offset
jitter
==============================================================================
xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 16 u - 64 0 0.000 0.000
4000.00
xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 16 u - 64 0 0.000 0.000
4000.00
-xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 1 u 17 64 17 68.750 3.182
13.392
*xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 1 u 18 64 17 61.884 1.768
0.192
+xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 1 u 16 64 17 52.622 1.312
1.097
xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 16 64 17 29.031 5.313
1.475
+xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 17 64 17 42.836 2.494
0.274
-xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 12 64 17 21.412 4.334
0.305
-xxxxxxxxxxxxxxx xxxxxxxxxxxxxx 2 u 16 64 17 55.781 0.205
0.692
LOCAL(0) LOCAL(0) 10 l 12 64 17 0.000 0.000
0.001
ntpq> q
[root@mavis ~]# uptime
09:10:59 up 5 min, 7 users, load average: 1.08, 0.96, 0.44
[root@mavis ~]# rpm -q ntp
ntp-4.2.0.a.20040617-4.EL4.1
[root@mavis ~]# uname -a
Linux mavis.localdomain 2.6.9-34.0.2.EL #1 Fri Jul 7 19:24:57 CDT 2006
i686 athlon i386 GNU/Linux
[root@mavis
~]#
Has anyone else seen this?
I always run a ntpdate at startup against my time server then start the
ntpd service. I am using the new smp kernel and ntpd on 3 machines and
it seems to be working. None of my machines are AMD though.
I think I might try pulling that SCSI card in the next day or so just
because this m/b BIOS wants to ignore it.
Thanks again to all who responded.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
