IMO this is to be expected and not a problem. In the case of offset of
'-1' the time will jump one usec forward on the timer interrupt, but
that's harmless and nothing worse should happen.
> and that along with the fact that I'm
> seeing a steady drift forward on every kernel I've run (2.4/2.5) makes
> me think that the timer interrupt frequency may be a bit higher then we
> intend. Might just be the dev hardware I'm running on, though.
The devel hardware's RTC crystals are quite a bit off the correct
frequency, but still in the range fixable by NTP.
> I'm also got some cleanup changes I'd like to make, but I'll wait until
> after things work to polish that stuff up.
>
> Let me know if you have any issues with this patch.
Looks OK to me.
> thanks
> -john
>
> diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
> --- a/arch/x86_64/kernel/time.c Wed Jun 11 17:28:07 2003
> +++ b/arch/x86_64/kernel/time.c Wed Jun 11 17:28:07 2003
> @@ -254,11 +254,14 @@
> vxtime.last = offset;
> } else {
> offset = (((tsc - vxtime.last_tsc) *
> - vxtime.tsc_quot) >> 32) - tick_usec;
> + vxtime.tsc_quot) >> 32) - (USEC_PER_SEC/HZ);
> + /* sanity check on offset */
> + if(offset < 0)
> + offset = 0;
>
> - if (offset > tick_usec) {
> - lost = offset / tick_usec;
> - offset %= tick_usec;
> + if (offset > (USEC_PER_SEC/HZ)) {
> + lost = offset / (USEC_PER_SEC/HZ);
> + offset %= (USEC_PER_SEC/HZ);
> }
>
> vxtime.last_tsc = tsc - vxtime.quot * delay / vxtime.tsc_quot;
> @@ -275,10 +278,7 @@
> "tick(s)! (rip %016lx)\n",
> (offset - vxtime.last) / hpet_tick - 1,
> regs->rip);
> - // XXX The accounting of lost ticks is way off right
> - // now. -bos
> -
> - // jiffies += lost;
> + jiffies += lost;
> }
>
> /*
>
>
>
-- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/