Timecounter: Missing memory barriers for th_generation read/write

[Nick Withers]

sptests/spnsext01 fails, with:

*** BEGIN OF TEST SPNSEXT 1 ***                                                                                                                     
../../../../../../../../rtems/c/src/../../testsuites/sptests/spnsext01/init.c: 50 !_Timespec_Less_than(&new_uptime, &uptime)

One issue is an integer overflow in c/src/lib/libcpu/powerpc/mpc6xx/clock/c_clock.c, resolved with:

-  Clock_TC.tc_frequency = (1000 * BSP_bus_frequency) / BSP_time_base_divisor;
+  Clock_TC.tc_frequency = ((uint64_t) 1000U * BSP_bus_frequency) / BSP_time_base_divisor;

(4 B two's-complement ints, uint32_t BSP_bus_frequency = 333333333)

With that sorted, a problem persists (spnsext01 still fails in the same way).

The test case I whacked together for #2230 (see ​https://lists.rtems.org/pipermail/users/2014-November/028354.html ) reports e.g.:

Starting, 100 ticks/s...
Time went backwards, from {0, 0} to {-1, 2235312}
Time went backwards, from {0, 9985584} to {-1, 999986991}
Time went backwards, from {0, 69984649} to {0, 59986009}
Time went backwards, from {0, 109984009} to {0, 99985369}
Time went backwards, from {0, 199982546} to {0, 189983906}
Time went backwards, from {0, 249981747} to {0, 239983131}
Time went backwards, from {0, 309980788} to {0, 299982148}
Time went backwards, from {0, 339980309} to {0, 329981669}
Time went backwards, from {0, 399979350} to {0, 389980710}
Time went backwards, from {0, 429978870} to {0, 419980230}
Time went backwards, from {0, 439978710} to {0, 429980142}
Time went backwards, from {0, 529977272} to {0, 519978632}
Time went backwards, from {0, 569976656} to {0, 559978016}
Time went backwards, from {0, 579976473} to {0, 569977880}
Time went backwards, from {0, 669975034} to {0, 659976394}
Time went backwards, from {0, 709974395} to {0, 699975755}
Time went backwards, from {0, 749973755} to {0, 739975115}
Time went backwards, from {0, 799972980} to {0, 789974340}
Time went backwards, from {0, 839972317} to {0, 829973701}
Time went backwards, from {0, 899971358} to {0, 889972694}
Time went backwards, from {0, 939970718} to {0, 929972102}
Time went backwards, from {1, 69968665} to {1, 59970024}
Time went backwards, from {1, 99968185} to {1, 89969569}
Time went backwards, from {1, 149967362} to {1, 139968722}
Time went backwards, from {1, 199966563} to {1, 189967922}
Time went backwards, from {1, 269965444} to {1, 259966803}
Time went backwards, from {1, 319964644} to {1, 309966004}
Time went backwards, from {1, 409963206} to {1, 399964566}
Time went backwards, from {1, 469962247} to {1, 459963607}
...

So it looks to me like it's potentially off by a tick again (same underlying issue as #2230?) and there's also something interesting going on with the seconds going negative...

[Sebastian Huber <sebastian.huber@…>]

In aff220db7a20b58014044848cbd1c37a226e635e/rtems:

bsps/powerpc: Fix potential integer overflow

Update #2356.

[Sebastian Huber]

The psim BSP uses the same clock driver and here the test works.

[Nick Withers]

Replying to sebastian.huber:

The psim BSP uses the same clock driver and here the test works.

I just tried to reproduce spnsext01 failing on the MVME3100 a few times and wasn't successful... Maybe I was wrong about it failing, but I think I may just have got lucky (or unlucky) before.

My test does fail on the psim:

nick@nuc211:/home/nick/projects/rtems-time-backwards % psim-gdb ./test.debug 
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-freebsd10.1 --target=powerpc-rtems4.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test.debug...done.
Connected to the simulator.
Breakpoint 1 at 0x3978: file ../../../../../../../../rtems/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_global_handler.c, line 23.
Breakpoint 2 at 0x11f00: file ../../../../../../../rtems/c/src/../../cpukit/score/src/interr.c, line 36.
psim-cmds:5: Error in sourced command file:
No symbol "the_source" in current context.
(gdb) run
Starting program: /usr/home/nick/projects/rtems-time-backwards/test.debug 
warning: failed to reevaluate condition for breakpoint 1: No symbol "the_source" in current context.
OpenPIC Version 1.2 (2 CPUs and 17 IRQ sources) at 0x0C130000
OpenPIC Vendor 0 (Unknown), Device 0 (Unknown), Stepping 0
Overriding NumSources (17) from configuration with 16
OpenPIC timer frequency is 1 Hz
Starting, 100 ticks/s...
Time went backwards, from {0, 0} to {-1, 2902599}
Time went backwards, from {5, 10143599} to {5, 222199}
Time went backwards, from {7, 10182999} to {7, 261599}
Time went backwards, from {9, 10223299} to {9, 301899}
Time went backwards, from {10, 242899} to {9, 990324899}
Time went backwards, from {12, 282799} to {11, 990364799}
Time went backwards, from {22, 10483199} to {22, 561799}
Time went backwards, from {24, 10523499} to {24, 602099}
Time went backwards, from {25, 10543199} to {25, 621799}
Time went backwards, from {26, 10563399} to {26, 641999}
Time went backwards, from {27, 10583599} to {27, 662199}
...

I'll attach the code momentarily...

[Nick Withers]

Test case that shows time going backwards; build instructions in enclosed Makefile

[Sebastian Huber]

This is a bug in the FreeBSD code:

​https://lists.freebsd.org/pipermail/freebsd-hackers/2015-May/047778.html

[Sebastian Huber]

This should be fixed in RTEMS and FreeBSD. We have to add or improve a test case for this problem. I plan to work on this next Wednesday.

[Sebastian Huber]

See also:

​https://lists.freebsd.org/pipermail/freebsd-hackers/2015-June/047798.html

[Sebastian Huber]

Corresponding patch to FreeBSD:

​https://svnweb.freebsd.org/base?view=revision&revision=284178

[Sebastian Huber]

[e1d61fe2aaefa13c45154f7ffedf43fe4c0c4efd/rtems]