Messages in this thread | | | Date | Fri, 07 Jun 2002 20:37:12 -0700 | From | george anzinger <> | Subject | Re: 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/
| |