On Thu, Aug 21, 2014 at 3:03 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 20/08/14 16:05, Joel Sherrill wrote: >> >> >> On 8/20/2014 8:59 AM, Sebastian Huber wrote: >>> >>> On 20/08/14 15:53, Joel Sherrill wrote: >>>> >>>> On 8/20/2014 8:12 AM, Daniel Cederman wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> We are currently experiencing this bug reported by Sebastian Huber and >>>>>> I >>>>>> could not find any discussion on it on the list. I'm guessing that the >>>>>> simple solution of moving the call to Clock_driver_support_at_tick() >>>>>> to >>>>>> the critical section of _TOD_Tickle_ticks() is not an acceptable >>>>>> solution, given that it would be a call from score to the BSP? >>>> >>>> I don't have a problem with it. Some documentation may need to be >>>> updated to >>>> reflect the environment in which the bsp hook is called but I think it >>>> is pretty >>>> obvious it is called when an accurate timestamp is wanted. >>> >>> Its not that easy. This Clock_driver_support_at_tick() is part of >>> clockdrv_shell.h. What we need is a proper clock driver API. >>> >> Grrr.. I should have actually re-read the PR and not tried to remember >> the issue. >> Sorry. :( >> >> It looks like the entire sequence needs to be locked. What that exposes >> is >> another matter. >> > > The clock handling is entirely broken on SMP and not scalable. Our clock > infrastructure is only good enough for uni-processor systems, but even here > the usage of nanosecond timestamps is suboptimal. I would rather use > something like the FreeBSD time hands: > > http://phk.freebsd.dk/pubs/timecounter.pdf > Nice. It looks like it would take: 1) Convert the 64-bit timestamps into bintime: a split time_t 'seconds' + uint64_t 'frac' format. The math is shown in the paper. 2) A lock-free ring buffer for the timehands. 3) The timecounter structure that describes the hw clock source, and a way to register timecounters from BSPs. 4) Rewrite tick handling to do the refresh operation.
Did I miss anything? > Anyway I don't have a budget for this, so for the current ESA project I > would disable the nanoseconds support in case this bug hurts. > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
