Time going backwards with clock_gettime(CLOCK_MONOTONIC, ...)

[Nick Withers]

On Wed, 2014-11-12 at 18:57 -0600, Joel Sherrill wrote:
> 
> On November 12, 2014 6:54:31 PM CST, Nick Withers <nick.withers at anu.edu.au> wrote:
> >On Wed, 2014-11-12 at 07:19 +0100, Sebastian Huber wrote:
> >> On 12/11/14 02:41, Nick Withers wrote:
> >> > On Tue, 2014-11-11 at 07:53 +0100, Sebastian Huber wrote:
> >> >> >Hello Nick,
> >> >> >
> >> >> >what is the output of the spnsext01 test for this BSP/board?
> >> > Hrmm, doesn't look good:
> >> > ____
> >> >
> >> > *** BEGIN OF TEST SPNSEXT 1 ***
> >> >
> >../../../../../../../../rtems/c/src/../../testsuites/sptests/spnsext01/init.c:
> >66 !_Timespec_Less_than(&new_uptime, &uptime)
> >> > ____
> >> >
> >> > ...followed by a reset.
> >> 
> >> This shows that the nanoseconds extensions of the clock driver is
> >broken.  This 
> >> explains also your time going backwards problem.
> >
> >So I should look at the routine installed by
> >rtems_clock_set_nanoseconds_extension() for my BSP?
> >
> >In the case of the MVME3100, that seems to be
> >Clock_driver_nanoseconds_since_last_tick() in
> >c/src/lib/libcpu/powerpc/mpc6xx/clock/c_clock.c
> >
> >(I'm not totally sure if it's meant to be, since the BSP's Makefile.am
> >seems to refer to e500/clock.rel rather than e.g., the MVME5500's
> >mpc6xx/clock.rel, but I know nothing 'bout autotools!).
> That sounds like the file I tracked it down to when looking for the source. 

Ta. I think that's correct, too, as the e500 clock code pulls in the
mpc6xx c_clock.c ("e500_clock_rel_SOURCES = mpc6xx/clock/c_clock.c
mpc6xx/clock/c_clock.h").

I believe I know what's going on now:
  - The e500 hardware decrementer used for the nanosecond extension is
set to auto-reload, so it cycles freely
  - The wrap could happen while querying the decrementer value in (e.g.)
_TOD_Get_with_nanoseconds() with _TOD locked, before the tick's
incremented, thus giving us an earlier time than it should by a tick
period (10 ms here).

Does this sound reasonable? I've tested by breaking with a debugger in
_TOD_Get_with_nanoseconds() and observing that I can read a lesser value
(e.g, 0) from (*tod->nanoseconds_since_last_tick)() after a larger value
(e.g., 9999000).

If so I suppose I should run it past Till and perhaps go about removing
the auto-cycling, resetting it in the tick handler.

> Yes. Those are hard references to track down. There needs to be a better way.
> 
> >Thanks for your help, any suggestions appreciated as I'm really going
> >to
> >want to fix this...
-- 
Nick Withers

Embedded Systems Programmer
Department of Nuclear Physics, Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)