clock_gettime() result going backwards on LEON3?

[Miller, Scott A.]

It was actually pulled before I joined the project, so I am a bit fuzzy on the details, but I believe October 2013.    It appears to be a download of the RCC from Gaisler.  Here's VERSION:

samiller at buttercup:/project/RTEMS/rtems-4.10$ cat VERSION
RCC-1.1.99.12a. RTEMS-4.10, GCC 4.3.3

Scott

On Jun 23, 2015, at 9:39 AM, Joel Sherrill <Joel.Sherrill at OARcorp.com> wrote:



On 6/23/2015 9:11 AM, Miller, Scott A. wrote:
> Hello,
> 
> I'm observing that intermittently, that two successive calls to clock_gettime() will result in the 2nd timespec result being "before" the 1st timespec result.
> 
> Here's the code and some example output showing this:
> 
> <code snippet>
> 
> #include <rtems.h>
> #include <bsp.h>
> #define CONFIGURE_INIT
> 
> rtems_task Init(rtems_task_argument ignored);
> 
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER      1
> #define CONFIGURE_INIT_TASK_ATTRIBUTES               RTEMS_FLOATING_POINT
> #define CONFIGURE_INIT_TASK_STACK_SIZE               (10 * RTEMS_MINIMUM_STACK_SIZE)
> #define CONFIGURE_MAXIMUM_TASKS                      13
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> #define CONFIGURE_MAXIMUM_DRIVERS                    16
> #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS     32
> #define CONFIGURE_EXTRA_TASK_STACKS                  (10 * RTEMS_MINIMUM_STACK_SIZE)
> #define CONFIGURE_MAXIMUM_POSIX_MUTEXES              rtems_resource_unlimited(10)
> #define CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES  rtems_resource_unlimited(10)
> #define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES           rtems_resource_unlimited(10)
> #define CONFIGURE_UNIFIED_WORK_AREAS
> #include <rtems/confdefs.h>
> 
> ....
> 
>     struct timespec time1;
>     struct timespec time2;
>     uint32_t i = 0;
> 
>     while (TRUE) {
>         clock_gettime(CLOCK_REALTIME, &time1);
>         clock_gettime(CLOCK_REALTIME, &time2);
> 
>         if (time1.tv_sec == time2.tv_sec) {
>             if (time2.tv_nsec < time1.tv_nsec) {
>                 PRINTF("Violation!\n");
>                 PRINTF("%09u - %09u\n", time1.tv_sec, time1.tv_nsec);
>                 PRINTF("%09u - %09u\n", time2.tv_sec, time2.tv_nsec);
>             }
>         }
> 
>         i++;
> 
>         if (0 == (i % 1000)) {
>             PRINTF("Completed %d iterations...\n", i);
>         }
>     }
> 
> </code snippet>
> 
> <output>
> 
> (gdb) run
> Completed 1000 iterations...
> Completed 2000 iterations...
> Completed 3000 iterations...
> Violation!
> 000000000 - 169994000
> 000000000 - 160002000
> Completed 4000 iterations...
> Completed 5000 iterations...
> Completed 6000 iterations...
> Violation!
> 000000000 - 409994000
> 000000000 - 400002000
> Completed 7000 iterations...
> Completed 8000 iterations...
> Completed 9000 iterations...
> Completed 10000 iterations...
> Completed 11000 iterations...
> Violation!
> 000000000 - 769993000
> 000000000 - 760001000
> 
> </output>
> 
> I'm running RTEMS 4.10.99 against the LEON3 (GR712RC) BSP.
> 
> Is this expected behavior, or am I doing something incorrectly?

No it is not expected.

What date did you pull the code? Is it up to date?

> Thanks.
> 
> Scott
> 
> --
> 
> Scott Miller | 210-522-4249 | Senior Research Engineer | Southwest Research Institute
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985