Path: utzoo!attcan!uunet!lll-winken!ames!elroy!orion.cf.uci.edu!ucsd!rutgers!att!whuts!homxb!hocpa!rusty
From: rusty@hocpa.UUCP (M.W.HADDOCK)
Newsgroups: comp.sys.nsc.32k
Subject: Fix to ICM3216 w/ UoTBSD4.2 clock problem (whew!)
Keywords: BSD ICM clock fix
Message-ID: <509@hocpa.UUCP>
Date: 25 Jan 89 05:56:04 GMT
Organization: AT&T Consumer Products, Holmdel, N.J.
Lines: 76


OK, despite a nasty touch of the flu, or whatever it is that's going around
this week, it appears that I've found a fix for the rtc_clock.  My patches
are for the file "/usr/sys/16k/clock.c" and you'll need to recompile/relink
your kernal!  The symptom I was seeing (yours might differ but I can't see
how) was the console displaying

		rtc_clock: Off by 86400 seconds!!!

at a rate of about twice per minute which started on New Year's Eve.  Well,
the twice per minute comes from /etc/update which syncs the disks every
30-seconds.  If you kill this process you should not see this problem but
may Heaven help you if the system crashed.  Anyhow, this sync apparently
caused the real time clock to be compared to the file system time and the
differences 'tween the two were calculated to be around 86400 seconds.
Funny, that's the number of seconds in a day!  So, I traced though the above
file and did all the calendar/date crunching by hand until I discovered the
bug.  From the way I read the code, leap years were not handled correctly
when resetting the RT Clock and when calculating GMT-->seconds.  While I'm
not too sure of the consequences, the clock chip did not have the leap_year
counter in the Clock Setting Register properly set either so I fixed that as
well (the second change below).

As a side note, all of this code did come from NSC's SYS V R2R2 port which I
still have on tape.  I compared UoT's file to that of SysV and the code was
almost exactly the same 'cept that UoT's method to calculate seconds from
GMT didn't work for all cases and 1989 was the first year (in a while) that
caused things to break.  I can see how they made their mistakes in coding.
I guess someone stayed up to late one night.  :-)

Anyhoot, here's the patch to /usr/sys/16k/clock.c (or /sys/16k/clock.c).  It
can be applied by hand as it's simple enough.  It's been nearly 3 hours
since I rebooted with this patch and I haven't seen the clock complain about
being a day off yet.  I hope this really fixes the problem.  Let me know if
it doesn't!!!  Oh, in case there are source code differences, I bought my
BSD (binary license #2) around Feb-March of 1987 so it's possible that newer
versions of the distribution tape (WERE THERE ANY???) may already have this
fixed.  If so, please let me know about that too!

Oh well, enough for now and it's off to bed for me.  It's almost 1am and I'm
s'pose to be sick.

					-Rusty-

P.S. In disassembling the pcc's output it appears that any integer division
or multiplication by an integer power of two is done by division or
multiplication as opposed to simply shifting in the appropriate direction.
Phoo! :-)

====

% diff clock.c.old clock.c
151c151,152
< 	*rtc->rtc_csr = RTCCSR_24HOUR;
---
> 	/* *rtc->rtc_csr = RTCCSR_24HOUR;  I know SysVR2R2 does this too
> 			but it doesn't seem necessary since we do it RSN */
154c155
< 	*rtc->rtc_csr = RTCCSR_24HOUR | (gmtp->tm_year % 4);
---
> 	*rtc->rtc_csr = RTCCSR_24HOUR | ((gmtp->tm_year & 3) << 2);
243c244
< 		tim = (365 * y) + ((y - 1) / 4);
---
> 		tim = (365 * y) + ((y + 1) / 4);
253c254
< 		tim += (((i + 1) * 306) / 10) - ((y & 3) ? 64 : 63);
---
> 		tim += (((i + 1) * 306) / 10) - (((y+2) & 3) ? 64 : 63);


-- 
Rusty Haddock		{uunet!likewise,att,arpa}!hocpa!rusty
AT&T Consumer Products Laboratories - Human Factors Laboratory
Holmdel, New Joyzey 07733   (201) 834-1023  rusty@hocpa.att.com
** Genius may have its limitations but stupidity is not thus handicapped.