It is currently Tue, 14 Jul 2020 01:32:44 GMT



 
Author Message
 gettimeofday clock jump bug
Hi,

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.

I suspect that somehow the either do_gettimeoffset() or xtime.tv_usec in do_gettimeofday is returning a ridiculously large value. I would like to get to the bottom of this problem, but am not familiar with this part of the timing infrastructure. Has anyone seen this bug before? Would using a different locking mode (SMP  vs none SMP, or wahtever) possibly help this problem? Is there a document online describing how this works in Linux?  

In the meantime, I want to hack up a patch to fix this on my box. I'm thinking I could give up a few seconds of clock precision in exchange for monotonic clock behavior, and so I want to comment out the adjustments to usec. What are the possible ramifications of this hack?

Alan

Original do_gettimeofday:

void do_gettimeofday(struct timeval *tv)
{
        unsigned long flags;
        unsigned long usec, sec;

        read_lock_irqsave(&xtime_lock, flags);
        usec = do_gettimeoffset();
        {
                unsigned long lost = jiffies - wall_jiffies;
                if (lost)
                        usec += lost * (1000000 / HZ);
        }
        sec = xtime.tv_sec;
        usec += xtime.tv_usec;
        read_unlock_irqrestore(&xtime_lock, flags);

        while (usec >= 1000000) {
                usec -= 1000000;
                sec++;
        }

        tv->tv_sec = sec;
        tv->tv_usec = usec;

My proposed hack (for my system):

void do_gettimeofday(struct timeval *tv)
{
        unsigned long flags;
        unsigned long usec, sec;

        read_lock_irqsave(&xtime_lock, flags);
        usec = do_gettimeoffset();
        /* {
                unsigned long lost = jiffies - wall_jiffies;
                if (lost)
                        usec += lost * (1000000 / HZ);
        } */
        sec = xtime.tv_sec;
        usec = xtime.tv_usec;
        read_unlock_irqrestore(&xtime_lock, flags);

        while (usec >= 1000000) {
                usec -= 1000000;
                sec++;
        }

        tv->tv_sec = sec;
        tv->tv_usec = usec;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at   http://www.**-**.com/
Please read the FAQ at   http://www.**-**.com/



 Wed, 24 Nov 2004 07:01:37 GMT   
 gettimeofday clock jump bug

Hello Alan,

While developing the Linux Trace Toolkit, I've seen this bug occur on
at least the i386 and the PPC. I had written down a description of
how time-keeping is done in the kernel in order to get to the bottom of
the problem. I'm not sure if this is still acurate, but it's a starting
point nevetheless:
http://www.embeddedlinuxworks.com/articles/kernel_time.html

Cheers,

Karim

--
===================================================
                 Karim Yaghmour
               ka...@opersys.com
      Embedded and Real-Time Linux Expert
===================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



 Wed, 24 Nov 2004 07:01:43 GMT   
 gettimeofday clock jump bug

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.

-g

--
George Anzinger   geo...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



 Wed, 24 Nov 2004 07:01:59 GMT   
 gettimeofday clock jump bug

I've just looked at the i386 time.c source and can see no obvious way for -1
to be returned by do_gettimeoffset(). 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.

Hope this helps,

Ruth

--
Ruth Ivimey-Cook
Software engineer and technical writer.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



 Wed, 24 Nov 2004 08:00:16 GMT   
 gettimeofday clock jump bug
Hi,
I've got Abit KT7 and AMD Athlon system, and i have seen this happen while
running 2.4.18 (with 2.4.16 and later 2.4.19-pre8/9 it didn't happen)
There has been some discussion about it here
http://marc.theaimsgroup.com/?t=92577204900001&r=1&w=2

VanTo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



 Wed, 24 Nov 2004 08:40:06 GMT   
 gettimeofday clock jump bug

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.

And just where does time() get the time of day if not from
gettimeofday()?

--
George Anzinger   geo...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



 Wed, 24 Nov 2004 11:40:06 GMT   
 
   [ 6 post ] 

Similar Threads

1. AGAIN: Re: gettimeofday clock jump bug (on AMD 756)

2. gettimeofday clock jump bug

3. Is CLOCK_REALTIME the same as the clock under gettimeofday()

4. Clock jumping back 12 hours

5. Clock jumping 23 hours when starting INN1.4

6. Jumping system clock

7. gettimeofday(struct timeval *tp) but is in 2.4 gettimeofday(tp,tzp)

8. [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() not synchronised with gettimeofday())

9. java/43949: Port java/jump should install jump.jar in shared jars dir

10. probable hardware bug: clock timer configuration lost"


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software