On Sun, Dec 17, 2000 at 09:54:18PM +0100, Andries.Brouwer@cwi.nl wrote:
> What architecture?
i386
> What kernel version?
2.4.0-test13-pre2, but this has been happening for a while.
> Are you in fact running xntpd?
Yes.
> > According to the notes in the code, this should work if my RTC
> > is less than 15 minutes off... which I can guarantee it is.
>
> Well, since you looked at the source:
> For some randomly chosen kernel version and architecture it does
>
> if (abs(real_minutes - cmos_minutes) < 30) {
> update_cmos()
> } else {
> printk("set_rtc_mmss: can't update from %d to %d\n",
> cmos_minutes, real_minutes);
> }
>
> so if your cmos time is 0.001 sec ahead of your system time
> then around the hour you'll see
> set_rtc_mmss: can't update from 0 to 59
Ahh... I think I see. While the math says "if the diference between the
real time and the cmos time is less than 30 min", it doesn't recognize that
the time difference between 2:59 and 3:00 is only 1 min.
Hrm.. the logic to get this right is always the type of thing that gets
me... that's why I usually calculate things the UNIX way -- seconds since
an epoch.
> Of course, messing with the cmos clock at all was a rather bad idea,
> but that is a different discussion.
True enough... but, the question is, how do we fix this? Make the logic
more buff? Or change the algorithm to use something like minutes since the
epoch?
Matt
-- Matthew Dharm Home: mdharm-usb@one-eyed-alien.net Maintainer, Linux USB Mass Storage DriverWe can customize our colonels. -- Tux User Friendly, 12/1/1998
This archive was generated by hypermail 2b29 : Sat Dec 23 2000 - 21:00:20 EST