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

[Joel Sherrill]

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. 

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