Time going backwards with clock_gettime(CLOCK_MONOTONIC, ...)
chrisj at rtems.org
Thu Nov 13 01:01:38 UTC 2014
On 13/11/2014 11:57 am, 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 ***
>> 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
>> (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.
Does the debug info embed the file name in the object file ?
More information about the users