[lkml]   [1998]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectProblem with kernel-pll in 2.0.3x (at least)
I just found a problem with the kernel-pll in 2.0.34pre10 (well it
hasn't changed since at least 2.0.33 as far as I can tell). It only
affects Alpha hardware (though it would affect anything which has
__KERNEL_HZ set to a value much larger than 100).

On the alpha, asm-alpha/param.h defines __KERNEL_HZ to 1024 which is
fine, so tick being the number of uS between clock updates is
977. (well it should be ~977.5 but...).

However, which means that a single unit change in tick alters the
speed of the clock by 1024ppm. Again this isn't a real problem, but
linux/timex.h defines MAXFREQ as

#define MAXFREQ (200L << SHIFT_USEC) /* max frequency error (ppm) */

so the kernel pll will not permit the frequence to be changed by more
than +/- 200ppm. I think this should be (2 * HZ)ppm. If this is a
really bad idea please let me know! Can this be added to 2.0.34 (and
2.1.x if appropriate)?

My poor little alpha clocks arn't within 200ppm so the clock adjust
can't cope, and altering the tick doesn't help as it isn't that far

As an aside can anyone tell me a good reason why ntp_adjtime() and
ntp_gettime() are not implemented in glibc (2.0.7 and earlier don't
have them). Not putting them in libc makes xntpd3 have to work much
harder to use the kernel-pll (xntp3-5.93 won't detect it at all on my
alphas without much hackery. I can provide trivial wrappers to
__adjtimex() if anyone wants them. When I reported the problems to the
xntpd maintainers they suggested I switch to FreeBSD!

Jon Peatfield, DAMTP, Computer Officer, University of Cambridge
Telephone: +44 1223 3 37852 Mail:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.072 / U:10.336 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site