alpha - generic_init_pit - why using RTC for calibration?

From: Oleg I. Vdovikin (
Date: Fri Jun 29 2001 - 07:20:59 EST


    we've a bunch of UP2000/UP2000+ boards (similar to DP264) with 666MHz
EV67 Alphas (we're building large Alpha cluster). And we're regulary see
"HWRPB cycle frequency bogus" and the measured value for the speed in the
range of 519 MHz - 666 MHz. And this value changes in this range from boot
to boot. So why this happens???

    Initialy we've an idea this boards has frequency stability problem. But
then I've decided to add simple recalculation for est_cycle_freq on every
1024 ticks which happens on boot processor (I've used rpcc for the
counting). I've added 10 lines to the timer_interrupt function. And I was
really wondered: the clock are rock solid - near 666 MHz and +- 1Khz
stability (I'm thinking it's some non constant overhead in the irq

    So, I've looked deeper. And here is the question: why using RTC for
calibration and UIP bit? This bit guarantees nothing - the specs said when
it's raised to 1 if clock update occures in the ~244 ms! But it does not
said this happens regulary in the same time for this 244 ms!

    So, the final question: why we're not using the aproach which is used by
x86 time.c? I.e. why not to use CTC channel 2 for calibration?

    Please correct me, if there is something wrong.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:21 EST