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