*** clockdiff.c.old Mon Oct 28 09:33:45 1996
--- clockdiff.c Mon Oct 28 09:33:27 1996
***************
*** 268,274 ****
#endif
dif = system_sec - cmos_sec;
! txc.mode = 0;
if (adjtimex(&txc) < 0)
perror("compare: adjtimex");
--- 268,274 ----
#endif
dif = system_sec - cmos_sec;
! txc.modes = 0;
if (adjtimex(&txc) < 0)
perror("compare: adjtimex");
***************
*** 276,282 ****
(long) cmos_sec,
dif,
dif - dif_prev,
! txc.frequency,
txc.tick,
txc.offset);
dif_prev = dif;
--- 276,282 ----
(long) cmos_sec,
dif,
dif - dif_prev,
! txc.freq,
txc.tick,
txc.offset);
dif_prev = dif;
On Fri, 25 Oct 1996, Benjamin C R LaHaise wrote:
>Ever since 1.3.x (0 <= x <= 35), my CMOS clock tends to loose ~4000
>seconds per day when the machine is on, but it does not when the machine
>is off. This behaviour seems to be related to the kernel updating the
>CMOS clock while the system is running, but I can't see anything that
>would cause different behaviour from 1.2.13 (which didn't munge the
>clock). Perhaps some CMOS clocks are buggy when being updated? If
>someone who is more familiar with the kernel's timing code could shed
>some light on the subject, I'd be quite appreciative.
>
> -b
>