forked from Imagelibrary/rtems
870cf9695f
There are two places where we convert from a timecounter delta to a bintime delta: tc_windup and bintime_off. Both functions use the same calculations when the timecounter delta is small. But for a large delta (greater than approximately an equivalent of 1 second) the calculations were different. Both functions use approximate calculations based on th_scale that avoid division. Both produce values slightly greater than a true value, calculated with division by tc_frequency, would be. tc_windup is slightly more accurate, so its result is closer to the true value and, thus, smaller than bintime_off result. As a consequence there can be a jump back in time when time hands are switched after a long period of time (a large delta). Just before the switch the time would be calculated with a large delta from th_offset_count in bintime_off. tc_windup does the switch using its own calculations of a new th_offset using the large delta. As explained earlier, the new th_offset may end up being less than the previously produced binuptime. So, for a period of time new binuptime values may be "back in time" comparing to values just before the switch. Such a jump must never happen. All the code assumes that the uptime is monotonically nondecreasing and some code works incorrectly when that assumption is broken. For example, we have observed sleepq_timeout() ignoring a timeout when the sbinuptime value obtained by the callout code was greater than the expiration value, but the sbinuptime obtained in sleepq_timeout() was less than it. In that case the target thread would never get woken up. The unified calculations should ensure the monotonic property of the uptime. The problem is quite rare as normally tc_windup should be called HZ times per second (typically 1000 or 100). But it may happen in VMs on very busy hypervisors where a VM's virtual CPU may not get an execution time slot for a second or more. Reviewed by: kib MFC after: 2 weeks Sponsored by: Panzura LLC
Real-Time Executive for Multiprocessing Systems (RTEMS)
-------------------------------------------------------
RTEMS, Real-Time Executive for Multiprocessor Systems, is a real-time executive
(kernel) which provides a high performance environment for embedded
applications with the following features:
- standards based user interfaces
- multitasking capabilities
- homogeneous and heterogeneous multiprocessor systems
- event-driven, priority-based, preemptive scheduling
- optional rate monotonic scheduling
- intertask communication and synchronization
- priority inheritance
- responsive interrupt management
- dynamic memory allocation
- high level of user configurability
- open source with a friendly user license
Project git repositories are located at https://git.rtems.org/
RTEMS Kernel: : https://git.rtems.org/rtems/
RTEMS Source Builder : https://git.rtems.org/rtems-source-builder/
RTEMS Tools : https://git.rtems.org/rtems-tools/
RTEMS Documentation : https://git.rtems.org/rtems-docs/
RTEMS FreeBSD : https://git.rtems.org/rtems-libbsd/
Online documentation is available at https://docs.rtems.org/
RTEMS User Manual : https://docs.rtems.org/branches/master/user/index.html
RTEMS RSB Manual : https://docs.rtems.org/branches/master/rsb/index.html
RTEMS Classic API : https://docs.rtems.org/branches/master/c-user/index.html
RTEMS POSIX API : https://docs.rtems.org/branches/master/posix-users/index.html
RTEMS Doxygen for CPUKit : https://docs.rtems.org/doxygen/branches/master/
RTEMS POSIX 1003.1 Compliance Guide :
https://docs.rtems.org/branches/master/posix-compliance/index.html
- Details the standards base functionality and profiles RTEMS supportsXo
RTEMS Developers Wiki : http://devel.rtems.org
- Bug reporting, community knowledge and tutorials.
RTEMS Mailing Lists : https://lists.rtems.org/mailman/listinfo
- The RTEMS Project maintains mailing lists which are used for most
discussions:
* For general-purpose questions related to using RTEMS, use the rtems-users
ml: https://lists.rtems.org/mailman/listinfo/users
* For questions and discussion related to development of RTEMS, use the
rtems-devel ml: https://lists.rtems.org/mailman/listinfo/devel
The version number for this software is indicated in the VERSION file.