On 07/04/2022 15:16, Sebastian Huber wrote:
On 07/04/2022 15:10, gabriel.moy...@dlr.de wrote:
Which sequence of function calls and timings cases the problem? This
should be definitely a test case.
The generation is updated every time tc_windup() is called. So it is
more or less a race condition when it happens.
This is not a race condition. The sequence counter is supposed to ensure
a consistent state. You can't simply remove this.
Maybe the PPS support requires that we use two timehands even for the
uniprocessor configuration. For this, we have to understand under which
conditions and use cases the generation change is an issue.
In kern_tc.c there is this comment, which is a result from a discussion
on a FreeBSD mailing list:
/*
* In FreeBSD, the timehands count is a tuning option from two to 16. The
* tuning option was added since it is inexpensive and some FreeBSD
users asked
* for it to play around. The default value is two. One system which
did not
* work with two timehands was a system with one processor and a
specific PPS
* device.
*
* For RTEMS, in uniprocessor configurations, just use one timehand
since the
* update is done with interrupt disabled.
*
* In SMP configurations, use a fixed set of two timehands until someone
* reports an issue.
*/
We definitely need a test case for this corner case. Adding a second
timehand has a size impact. On a 32-bit machine there is sizeof(struct
timehands) == 120.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
