> Examples found:
> -0.009964 (about -1 tick!)
> -0.009935
i was wondering why it's always under 10000. Then i found that
one tick is 9976.70 usecs. (and do_fast_gettimeoffset() divides with
1000000/HZ, this should be changed to 997670/HZ)
> But still, this has nothing to do with my changes to the PLL
> code. The microtime() offset is just added to the kernel time. The
> kernel time itself shouldn't run backwards unless a adjtime() is in
> progrss. Well, adding a tick's value from time to time could be from
> adjtimex, but I think the changes should be smaller that one tick's
> value. If they aren't, then that's the thing I'm hunting for.
well, it's another problem, but from do_fast_gettimeoffset():
if (quotient >= 1000000/HZ)
quotient = 1000000/HZ-1;
return quotient;
this returns 1000000/Hz for a >whole< tick if we eventually loose one?
what puzzles me is that i get time warps on a 486 too. And most Pentium
systems dont use the 64 counter, since the source is #ifdef-ed with
CONFIG_APM. (my system has no APM for example).
-- mingo