#2356 closed defect (fixed)

Timecounter: Missing memory barriers for th_generation read/write

Reported by: Nick Withers Owned by: Sebastian Huber
Priority: high Milestone: 4.11
Component: unspecified Version: 4.11
Severity: blocker Keywords:
Cc: Blocked By:
Blocking:

Description

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

Attachments (1)

rtems-time-backwards.tar.bz2 (2.6 KB) - added by Nick Withers on May 29, 2015 at 7:41:21 AM.
Test case that shows time going backwards; build instructions in enclosed Makefile

Download all attachments as: .zip

Change History (9)

comment:1 Changed on May 29, 2015 at 7:00:41 AM by Sebastian Huber <sebastian.huber@…>

In aff220db7a20b58014044848cbd1c37a226e635e/rtems:

bsps/powerpc: Fix potential integer overflow

Update #2356.

comment:2 Changed on May 29, 2015 at 7:05:10 AM by Sebastian Huber

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

comment:3 in reply to:  2 Changed on May 29, 2015 at 7:38:18 AM by 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...

Changed on May 29, 2015 at 7:41:21 AM by Nick Withers

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

comment:4 Changed on May 29, 2015 at 1:22:15 PM by Sebastian Huber

Severity: criticalblocker

comment:5 Changed on May 31, 2015 at 6:18:25 AM by Sebastian Huber

Owner: set to Sebastian Huber
Status: newassigned
Summary: MVME3100: Time goes backwards, post-timecounter changesTimecounter: Missing memory barriers for th_generation read/write

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.

comment:8 Changed on Jun 9, 2015 at 1:21:02 PM by Sebastian Huber

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.