I wrote: > A GENERIC amd64 kernel compiled from today's sources is causing my > Asus k8v-se-d to run fast by approximately 3 seconds per minute. > (Obviously that was with ntpd not running.) This has never been a > problem before. Is anyone else seeing this?
Turns out this was caused by the most recent changes to kern_clock.c and kern_time.c. Compiling with these previous versions gave me a functional system clock again. /* $OpenBSD: kern_clock.c,v 1.56 2006/01/03 18:22:31 miod Exp $ */ /* $OpenBSD: kern_time.c,v 1.52 2005/11/28 00:14:29 jsg Exp $ */ I think I see how this slipped by testing. The problem only exhibited itself after I ran mills/udel ntpd briefly. This appeared to set a persistent and exceedingly large slew rate that never timed out. Ntpd can't clear it and stopping ntpd only freezes the slew at the last value. The udel ntpd also couldn't control the system clock too well when it was running. It would lose control of the system within minutes as the slew rate passed some magic rate (500ppm???). As the time offset got larger ntpd decided that all the reference clocks were "insane" and didn't even try to sync to them any more. My last tests showed a case with 1.5 second slew over a 10 second span. The following test showed the constant 1.5 sec/10 sec slew over the course of several hours. while : ; do ntpdate -d ntp.sonic.net ; sleep 10 ; done Hope this helps. -wolfgang
