fredb@immanent.net said:
> > So you are working on getting the scopeid/zone fixes into the ntp
> > tree?
> No, Danny Mayer is responsible for that. I didn't realize that was
> still not done. (Which bug # is that?)

The original bug report is #235. Some changes have been made to
the ntp code, but the scopeid is still not tracked.
Imho the best thing to do would be to update the lib/isc code
to something recent. At least the isc code should convince Danny
that the scopeid is worth keeping...

> By "keep up", I meant I'm trying to report promptly when the NetBSD
> build breaks.

Well, the snapshots build. If massaged into the NetBSD tree, one
gets some "type-punned pointer" warnings which break the build
with -Werror.
The ipv6 problems get only visible if one tries to use it. In simple
setups, even (unicast) link-local addresses work, but without the scope
id, the kernel might not be able to resolve routing ambiguities.
Link-local multicast reception fails completely.
There are also LP64 issues remaining, at least the "timeval" part
of bug #233 is still present.
(btw, I just acquired an old ultrasparc5. LP64 and BE together might
reveal more problems...)

What to do now? -- ntp seems to stabilize for a 4.2.1 release, so I'd
assume that they are not going to update their copy of libisc before
that. So we need a less invasive solution - just as the patches
in ntp bug #235. But since these patches were not accepted, it would
be a waste of time to update them for pre-4.2.1.

> I'm convinced there's a bug in the kernel for SMP.

Yep, there is something wrong. But just jitter caused by ntpd
running on the CPU catching the clock interrupt and the other
randomly shouldn't lead to a clearly systematical frequency
error. I believe that interrupts get lost, a more fundamental
problem in interrupt level handling. (The "TLB IPI redezvous"
problem suggests the same.)

best regards
Matthias