[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TS-7200: time sync issues
>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
>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
>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").
Main Index |
Thread Index |