gettimeofday seconds rollover problem?

[Joel Sherrill]

Andrew Sinclair wrote:

>Hello,
>
>Has anyone experienced issues with ticks rollover in a gettimeofday
>call? I have two calls to gettimeofday inside a task, and I am noting
>the difference in time. I have noticed infrequently that when the last
>timestamp occurs, the microseconds have rolled over to zero and the
>seconds remain at their previous value.
>
>So for example I am seeing... 
>Timestamp 1 : 1 second 998000usec
>Timestamp 2 : 1 second 0usec !!!
>
>Instead of 
>Timestamp 1 : 1 second 998000usec
>Timestamp 2 : 2 seconds 0usec
>
>Interestingly, another call very shortly after the incorrect time stamp
>returns the correct result. Ie.
>
>Timestamp 1 : 1 second 998000usec
>Timestamp 2 : 1 seconds 0usec !!!
>Timestamp 3 : 2 seconds 0usec
>
>I don't understand how this could happen, as rtems_clock_tick() is
>called within a timer interrupt, and the critical section in
>gettimeofday() is protected.
>Could it be caused by _TOD_Seconds_since_epoch not being volatile???
>
>  
>
The seconds and nanoseconds values are grabbed/computed with interrupts
disabled so I don't think that would be the problem.  The asm volatile 
statements
should provide sync points for the compiler if a partial read of memory 
were
an issue.

I was looking for a math mistake but don't see it either. It looks like 
ticks since
seconds boundary was zeroed and ticks since epoch wasn't incremented.

I just don't have a clue what you are seeing.  :(

Why are you getting 1 and 2 seconds?  Have you set the TOD?  Maybe there is
some weirdness in the behavior before time of day is set.  I don't think 
clock_gettime()
allows for the time never having been set as an error condition and it 
could be
a weird side-effect of time of day not really being set.

>My timebase is set for 1msec granularity, my target is coldfire, and I
>am using RTEMS 4.6.2, which has some fixes for problems discussed in the
>mailing list. These files seem unrelated to the issue at hand, however
>FYI they are timerfireafter.c, timerserverfireafter.c, and
>watchdoginsert.c. 
>
>  
>
I don't think this is it either.

>Any pointers?
>
>Kind Regards
> 
>Andrew Sinclair
>  
>