Re: TS-7200: time sync issues

[Ken Hornstein <kenh%cmf.nrl.navy.mil@localhost>]

>A P.S.  Looks like I'm wrong.  Looks like it uses tsrtc, which is a
>mc146818 device, which has a dangerous looking mc146818_settime_ymdhms
>function:
>[...]
>also done at splclock() (which I think may be unneeded these days).
>If the part takes a long time to reply...

Ouch, I missed the splclock() in mc146818.c.  Yeah, I don't know how
slow writes are to that bus, but that could be a likely culprit.  And
I even see that the splclock() call is marked "XXX really needed?".  And
as I trace back up the call path, I see that resettodr() is right after
the splx() call in kern_time.c, which tells me that the idea was that
the todr is NOT supposed to be set at splclock().  And now that I think
about it, I cannot come up with any reason why clock interrupts should be
blocked during the setting of the time-of-day clock; can anyone else?

>This is an easy theory to test: add a 'return 0' to the top of that
>function and see if the problem goes away.  We don't read the RTC
>while we're running, iirc, so it won't hurt anything...

I'll give that a try later today!  Thanks for the suggestion!

From Jesse Off <joff%embeddedARM.com@localhost>:
>I can offer to RMA Ken's TS-7200 and have someone test its crystal with 
>a accurate frequency counter out here.  The pins are very easy to get 
>to.  However, I really doubt its the hardware.  The way these crystals 
>fail is they stop oscillating altogether.  Usually, thats traced down to 
>being internally shattered from being dropped.

Thanks for the offer, Jesse!  But I think everyone agrees now that the
clock frequency is not the problem; the issue seems to be around the
code path that sets the time-of-day (my TS-7200 does have the optional
battery-backed RTC).

>Another suggestion I would have is to try an older NetBSD kernel.  I am 
>pretty sure I had tested time drift (since we were fighting it 
>simultaneously in Linux at the time) during the initial port and I'm 
>pretty sure I didn't notice obnoxious drift beyond what I expected. I 
>committed the bulk of ep93xx and TS-7200 code in 2004 and there has been 
>changes since then that I do not recognize.  Specifically, the addition 
>of the timecounters(4) API and it looks like somebody added support for 
>non-64HZ tick rates.

Actually, this is not a new problem; it has existed for a long time, way
before timecounter support went in.  I just haven't had the free time to
run it down until now, and that was only after I worked out all of the
issues with the INSTALL kernel (which really all boiled down to, "The
kernel is too big").

--Ken