[RTEMS Project] #2356: MVME3100: Time goes backwards, post-timecounter changes

[RTEMS trac]

#2356: MVME3100: Time goes backwards, post-timecounter changes
--------------------------+------------------
 Reporter:  nick.withers  |      Owner:
     Type:  defect        |     Status:  new
 Priority:  high          |  Milestone:  4.11
Component:  General       |    Version:  4.11
 Severity:  critical      |   Keywords:
--------------------------+------------------
 ''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 ''int''s, ''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...

--
Ticket URL: <http://devel.rtems.org/ticket/2356>
RTEMS Project <http://www.rtems.org/>
RTEMS Project