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

Nick Withers nick.withers at anu.edu.au
Thu Nov 13 00:54:31 UTC 2014


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

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)



More information about the users mailing list