Russell King wrote:
>
> Eli Carter writes:
> > What are you seeing that I'm missing?
>
> Ok, after sitting down and thinking again about this problem, its not
> the 9.9999ms case, but the 10.000000001 case:
[snip]
> Like I say, this requires good timing to create, so may not be too much of
> a problem, but it does seem to be a problem that could occur.
It appears that this problem is easier to create than we originally gave
credit for.... All that is needed is for gettimeoffset() not to be
called for a _minimum_ of >10ms, and for the timer to wrap during a call
to do_gettimeofday() or during a period of time where interrupts are
disabled and do_gettimeofday() is called. Note that there is no upper
limit to the time...
If we call gettimeoffset() after do_timer() returns (and there-by update
the internal variables every 10ms), we should reduce the impact of this
bug dramatically (in theory--in practice, disabling interrupts for long
periods can also have some bad effects that this won't help, but I think
that's another issue.)
One of the guys I'm working with did some testing on this, and he was
seeing this problem (off by 10ms) every 5 to 10 minutes (on a modified
ARM & kernel). With the additional gettimeoffset() call, he no longer
saw it (at least within ~3hrs.).
Questions, comments, etc.?
Eli
-----------------------. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
eli.carter(at)inet.com `------------------ helps if you know the answer.
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:16 EST