lkml.org 
[lkml]   [2002]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday clock jump bug
Ruth Ivimey-Cook wrote:
>
> ashieh@OCF.Berkeley.EDU wrote:
> > time() occasionally returns a
> >bogus value (>1 hour jump forward, and a few microseconds later jumps back to
> >the right time) on my box (Thunderbird 750, Asus K7V (KX133) kernel 2.4.17).
> >This behavior sets in after the box is up for some period of time. I don't
> >think this is related to the 686a configuration reset bug.
> >
> On Fri, 7 Jun 2002, george anzinger wrote:
> >I suspect that do_gettimeoffset() may be, on occasion,
> >returning a negative number. The normalizing code then
> >works with this (unsigned) value until it is < 1,000,000.
> >If it came back as -1, this would generate an error of about
> >1.19 hours. I suspect the best fix would be to test the
> >result from do_gettimeoffset() for something greater than
> >say 20ms and if so set it to 0.
>
> I've just looked at the i386 time.c source and can see no obvious way for -1
> to be returned by do_gettimeoffset().

It can happen two ways (and I am not saying it returns -1,
but some large number ~ 1hr worth of usecs). The first
possibility is an overflow in the conversion of tsc ticks to
usec. This is more likely a problem if the processor is
running at high speeds, AND interrupts have been held off
for a while. The second possibility is that either the
latch read failed to latch or the PIT is actually not
resetting at count = 0. This is, I think, the VIA chip
bug. If there is no "correction" code for this bug, the net
result will be a slow and erratic clock. If there is
correction software in place, it could result in the
observed time jump by providing an invalid count which is
then used by do_gettimeoffset(). The reason the fault
clears is a.) on the next tick a valid count will be
obtained, and b) the value from do_gettimeoffset() is never
rolled into the wall clock.

> I note that this error is fixed in the
> next time() call, so I would instead expect the error to be one involving the
> conversion of tv_secs/tv_usecs into the seconds return from time().
>
> One possible way to check this out would be to change the test program from
> using the time() call to using gettimeofday(), and to ignore tv_usecs.

And just where does time() get the time of day if not from
gettimeofday()?
>
> Hope this helps,
>
> Ruth
>
> --
> Ruth Ivimey-Cook
> Software engineer and technical writer.

--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
-
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/

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