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 :) :
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.