gettimeofday seconds rollover problem?

[Andrew Sinclair]

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???

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. 

Any pointers?

Kind Regards
 
Andrew Sinclair