![[RTEMS Logo]](/images/logo.png){kind=logo}
Timeline
11/11/21:
- 21:08 Ticket #4547 (dtc build failure on msys2 - all rtems6 target tools fail to build on ...) created by kgardas
- I'm testing RSB git source updated 2021-11-10 and it fails on freshly …
- 19:04 Changeset in rtems-central [19f078f] by Sebastian Huber <sebastian.huber@…>
- spec: Add a test scenario with a sticky node
- 17:54 Ticket #2902 (Port RTEMS to Microblaze) closed by Joel Sherrill
- fixed: A Microblaze port and BSP for the KCU105 (HW and Qemu) have been merged. LWIP and libbsd should be supported soon. Closing.
- 17:54 Changeset in rtems-central [8aae088] by Sebastian Huber <sebastian.huber@…>
- spec: Fix comment
- 16:05 Changeset in rtems-central [ec7b4ca] by Sebastian Huber <sebastian.huber@…>
- modules: Update rtems
- 13:23 Changeset in rtems [6cef3f16] by Sebastian Huber <sebastian.huber@…>
- score: Do not shadow parameter
- 10:03 Changeset in rtems-central [a4a40d8] by Sebastian Huber <sebastian.huber@…>
- spec: Update due to score API changes
- 09:34 Changeset in rtems [e429e97] by Sebastian Huber <sebastian.huber@…>
- score: Simplify thread wait state handling Remove the THREAD_WAIT_STATE_READY_AGAIN and simply use the initial value to indicate that a thread does not wait on something. Rename THREAD_WAIT_FLAGS_INITIAL to THREAD_WAIT_STATE_READY. This change is necessary so that _Thread_Continue() can be called for threads which never waited on something (for example dormant threads). Update #4546.
- 08:00 Changeset in rtems [2e56aab] by Sebastian Huber <sebastian.huber@…>
- score: Move _Thread_queue_Extract() Move _Thread_queue_Extract() since this function is not used by the core services (threads, semaphores, mutexes, message queues). Update #4546.
- 07:44 Changeset in rtems [5468464] by Sebastian Huber <sebastian.huber@…>
- score: Properly continue the thread during restart The _Thread_queue_Extract() does not deal with potential priority updates and the SMP locking protocol handling. Use _Thread_queue_Continue(). For the POSIX signals processing this is currently probably unnecessary, however, the use case is similar to the restart so use the same appoach. Close #4546.
- 07:35 Changeset in rtems [50aef135] by Sebastian Huber <sebastian.huber@…>
- score: Add _Thread_MP_Extract_proxy() Remove _Thread_queue_Extract_with_proxy() and move the proxy extraction to _Thread_MP_Extract_proxy(). Move similar code blocks of the previous caller of _Thread_queue_Extract_with_proxy() to helper functions. Update #4546.
- 07:33 Changeset in rtems [cd791039] by Sebastian Huber <sebastian.huber@…>
- score: Remove thread timer earlier The earlier we remove the thread timer the less likely is a superfluous thread timeout processing. Update #4546.
11/10/21:
- 18:27 Changeset in rtems-source-builder [dbc11a8] by Karel Gardas <karel@…>
- RSB: add GRUB2 to the RTEMS tools and use it in 6/rtems-x86_64 build set
- 17:00 Ticket #4546 (A thread restart does not update the priority of related threads) created by Sebastian Huber
- Consider the following scenario. Let a high priority task H wait on a …
- 10:11 Changeset in rtems-central [6d35128] by Sebastian Huber <sebastian.huber@…>
- spec: Improve processor removal specification
- 08:27 Ticket #4545 (The SMP EDF scheduler can only support more restricted affinity sets ...) created by Sebastian Huber
- The SMP EDF scheduler supports a one-to-one and one-to-all thread to …
- 08:15 Changeset in rtems [69aaf587] by Sebastian Huber <sebastian.huber@…>
- libtest: Improve the interrupt test timing If no state change occurred during the test action, then assume a late interrupt.
- 07:54 Changeset in rtems [6443c9d] by Sebastian Huber <sebastian.huber@…>
- score: Fix assertion in SMP scheduler framework Properly assert that the scheduled chain is not empty. Fix formatting. Close #4531.
11/09/21:
- 17:06 Ticket #4145 (rtems-source-builder: Update RTEMS Kernel Recipe to Use waf for RTEMS) closed by Ryan Long <ryan.long@…>
- fixed: In def9347/rtems-source-builder: […]
- 15:47 Changeset in rtems [8b21a1b9] by Elvira Khabirova <e.khabirova@…>
- libfdt: fix an incorrect integer promotion UINT32_MAX is an integer of type unsigned int. UINT32_MAX + 1 overflows unless explicitly computed as unsigned long long. This led to some invalid addresses being treated as valid. Cast UINT32_MAX to uint64_t explicitly. Signed-off-by: Elvira Khabirova <e.khabirova@…>
- 15:11 Changeset in rtems-central [214d7d3] by Sebastian Huber <sebastian.huber@…>
- spec: Specify ask for help request
- 14:51 Changeset in rtems-central [8cefdc1] by Sebastian Huber <sebastian.huber@…>
- modules: Update rtems
- 12:47 Changeset in rtems-central [283aa86] by Sebastian Huber <sebastian.huber@…>
- spec: Specify ask for help details
11/08/21:
- 14:34 Changeset in rtems-central [3fcf994] by Sebastian Huber <sebastian.huber@…>
- spec: Specify scheduler yield
- 12:26 Changeset in rtems-central [77400c8] by Sebastian Huber <sebastian.huber@…>
- spec: Fix issue with RTEMS_DEBUG
- 10:08 Changeset in rtems [c69a70a] by Sebastian Huber <sebastian.huber@…>
- rtems: Fix rtems_scheduler_remove_processor() Return an error status for the following error condition in rtems_scheduler_remove_processor(): While an attempt is made to remove a processor from a scheduler, while the processor is the only processor owned by the scheduler, if a thread exists which uses the scheduler as a helping scheduler, then the processor shall not be removed. The reason is that ask for help requests and withdraw node requests are processed asynchronously in any order. An ask for help request carried out on a scheduler without a processor is undefined behaviour. Update error status description. Update #4544.
- 09:44 Ticket #4544 (The last processor must not be removed if it is owned by a helping ...) created by Sebastian Huber
- The following error condition is currently not checked by …
- 09:26 Changeset in rtems-central [d6db730] by Sebastian Huber <sebastian.huber@…>
- validation: Move support code before fixture
- 08:58 Changeset in rtems-central [d2c27b8] by Sebastian Huber <sebastian.huber@…>
- spec: Remove processor special case
11/07/21:
- 22:15 Changeset in rtems-source-builder [6bc7cac] by Joel Sherrill <joel@…>
- config/[67]/rtems-*.bset: Move dtc to default set
- 22:15 Changeset in rtems-source-builder [09498ee] by Joel Sherrill <joel@…>
- rtems-tools-6.cfg: Bump rtems-tools hash
11/05/21:
- 19:16 Changeset in rtems-central [91b8e87] by Sebastian Huber <sebastian.huber@…>
- spec: Fix integer constant
11/04/21:
- 19:25 Changeset in rtems-source-builder [33d8196] by Kinsey Moore <kinsey.moore@…>
- rtems-gcc-10-newlib-head: Uncomment patch lines These lines were accidentally committed with a leading + which resulted in them being non-functional. This restores them to functionality such that the patch gets downloaded and applied appropriately.
- 15:43 Ticket #4501 (TraceConverter.cc: Uncaught exception issue spotted by Coverity) closed by Ryan Long <ryan.long@…>
- fixed: In d1df4f6/rtems-tools: […]
- 03:39 Ticket #4104 (RSB Tools newlib patch checksum fails.) reopened by Benjamin Garner
- Checksum has broken again for this patch, 4.11 branch failing to build.
11/03/21:
- 18:35 Changeset in rtems [ef207e9] by Kinsey Moore <kinsey.moore@…>
- bsps/aarch64: Restore interrupt nesting Fixing the debug mask flag broke nested interrupts. This restores that functionality.
- 14:22 Ticket #4543 (cannot build multiprocessor application on eclipse) created by mohamedosama94
- Hi, hope my mail finds you well, i have an issue as i am using rtems6 …
- 01:23 Ticket #4542 (filename length problem in JFFS2 with RTEMS4.11.3/RTEMS5.1) created by chenjin_zhong
- Hi, the MACRO JFFS2_MAX_NAME_LEN defines the maximum length of …
11/01/21:
- 19:40 Changeset in rtems-docs [a0bf79c] by Kinsey Moore <kinsey.moore@…>
- c-user: Update for application CONFIGURE option This adds the documentation for the application configuration option CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING.
- 19:37 Changeset in rtems-central [08fd839] by Kinsey Moore <kinsey.moore@…>
- spec: CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
- 18:52 Changeset in rtems-docs [ac8f461] by Kinsey Moore <kinsey.moore@…>
- cpu-supplement: Update AArch64 SMP details AArch64 now supports SMP for the Xilinx ZynqMP BSP family.
- 14:54 Ticket #4541 (rtems_jffs2_rmnod function problem) created by chenjin_zhong
- Hi, the dir_i->i_mode must be S_IFDIR in this situation.therefore, I …
10/29/21:
- 19:12 Changeset in rtems [a678d1a] by Kinsey Moore <kinsey.moore@…>
- cpukit: Compare the function result Compare the function result instead of the function pointer for non-SMP builds.
- 18:29 Changeset in rtems [1640657]5 by Mark Johnston <markj@…>
- timecounter: Load the currently selected tc once in tc_windup() Reported by: Sebastian Huber <sebastian.huber@…> Reviewed by: kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32729
- 18:29 Changeset in rtems [c3a68059] by Mark Johnston <markj@…>
- timecounter: Load the currently selected tc once in tc_windup() Reported by: Sebastian Huber <sebastian.huber@…> Reviewed by: kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32729
- 17:44 Changeset in rtems-central [b10a624] by Sebastian Huber <sebastian.huber@…>
- modules: Update rtems
- 17:29 Changeset in rtems-central [b955aff] by Sebastian Huber <sebastian.huber@…>
- spec: Improve set task priority specification
- 17:12 Ticket #4540 (Healthcare Mailing Lists) closed by Joel Sherrill
- invalid
- 17:08 Ticket #4540 (Healthcare Mailing Lists) created by Albert
- Removed all links as spam.
- 12:45 Changeset in rtems [d0434b88] by Sebastian Huber <sebastian.huber@…>
- score: Remove victim thread from CPU allocation Update #4531.
- 12:17 Changeset in rtems [4d90289e] by Sebastian Huber <sebastian.huber@…>
- score: _Scheduler_SMP_Schedule_highest_ready() Simplify callers of _Scheduler_SMP_Schedule_highest_ready(). Move the node state change and the extraction from scheduled into _Scheduler_SMP_Schedule_highest_ready(). Move the idle thread release to the caller which have more information about the presence of an idle thread. Update #4531.
- 11:57 Changeset in rtems [3c076041] by Sebastian Huber <sebastian.huber@…>
- score: Simplify _Scheduler_Generic_block() If we block the executing thread and it is not the heir thread, then there is no need to run the schedule operation. The scheduler already selected a new heir.
- 11:44 Changeset in rtems [c6362f6] by Sebastian Huber <sebastian.huber@…>
- score: Move _Scheduler_Unblock_node() Move _Scheduler_Unblock_node() into _Scheduler_SMP_Unblock(). This simplifies the code and makes it easier to review. Update #4531.
- 11:38 Changeset in rtems [dcd8b93] by Sebastian Huber <sebastian.huber@…>
- score: Move _Scheduler_Block_node() Move _Scheduler_Block_node() into _Scheduler_SMP_Block(). This simplifies the code and makes it easier to review. Update #4531.
- 07:30 Changeset in rtems [fc64e837] by Sebastian Huber <sebastian.huber@…>
- score: Rework ask for help requests Process ask for help requests on the current processor. This avoids using inter-processor interrupts to make the system behaviour a bit more predictable. Update #4531.
- 06:29 Changeset in rtems [f767ef80] by Sebastian Huber <sebastian.huber@…>
- score: Simplify _Scheduler_SMP_Yield() There is not need to actively ask for help in a yield operation. The helping is already done on demand by the other scheduler operations.
- 06:27 Ticket #4539 (rtems_filesystem_table compile) created by chenjin_zhong
- Hi, when the macro CONFIGURE_APPLICATION_DISABLE_FILESYSTEM is …
- 06:21 Changeset in rtems-central [80df20f] by Sebastian Huber <sebastian.huber@…>
- spec: Specify MrsP uniprocessor scheduler detail
- 05:12 Changeset in rtems-central [87720a6] by Sebastian Huber <sebastian.huber@…>
- spec: Check that NTP update second is not called
10/28/21:
- 19:58 Changeset in rtems-tools [ba4648b] by Alex White <alex.white@…>
- rtems-bsp-builder: Fix mail support This fixes a problem with mailer options support that occurred because check.py uses argparse.ArgumentParser? instead of tester.rt.options.
- 19:58 Changeset in rtems-tools [bdd785a]5 by Alex White <alex.white@…>
- rtems-bsp-builder: Fix mail support This fixes a problem with mailer options support that occurred because check.py uses argparse.ArgumentParser? instead of tester.rt.options. Closes #4553
- 19:21 Changeset in rtems-central [a827b7c] by Sebastian Huber <sebastian.huber@…>
- spec: Fix typo
- 18:57 Changeset in rtems-central [7bdca91] by Sebastian Huber <sebastian.huber@…>
- modules: Update rtems
- 18:29 Ticket #4536 (acess JFFS2 sb->s_root) closed by Sebastian Huber
-
invalid: Replying to chenjin_zhong:
> Replying to Sebastian Huber:
> > Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance:
> > {{{#!c
> > static void rtems_jffs2_do_lock(struct super_block *sb)
> > {
> > rtems_recursive_mutex_lock(&sb->s_mutex);
> > }
> >
> > static void rtems_jffs2_do_unlock(struct super_block *sb)
> > {
> > rtems_recursive_mutex_unlock(&sb->s_mutex);
> > }
> > }}}
>
> Suppose that a GC thread or other thread/task calls jffs2_garbage_collect_pass, and then operates sb->s_root by jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for each JFFS2 instance can't work.
It is not a high performance approach, but it works. See
testsuites/fstests/fsjffs2gc01/init.c. - 18:26 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) closed by Sebastian Huber
-
invalid: Replying to chenjin_zhong:
> Replying to Sebastian Huber:
> > Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.
>
> Thank you! I got it. but we Suppose that a GC thread or other thread/task and main task calls jffs2_do_readinode simultaneous. a global lock for each JFFS2 instance can't work.
It is not a high performance approach, but it works. See
testsuites/fstests/fsjffs2gc01/init.c. - 18:17 Changeset in rtems-central [611b9a2] by Sebastian Huber <sebastian.huber@…>
- modules: Update rtems
- 16:54 Changeset in rtems-tools [d1df4f6] by Ryan Long <ryan.long@…>
- TraceConverter?.cc: Add catch for exception CID 1471639: Add catch for exception Closes #4501
- 15:07 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) reopened by chenjin_zhong
- 14:53 Ticket #4536 (acess JFFS2 sb->s_root) reopened by chenjin_zhong
- Replying to Sebastian Huber: > Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: > {{{#!c > static void rtems_jffs2_do_lock(struct super_block *sb) > { > rtems_recursive_mutex_lock(&sb->s_mutex); > } > > static void rtems_jffs2_do_unlock(struct super_block *sb) > { > rtems_recursive_mutex_unlock(&sb->s_mutex); > } > }}} Suppose that a GC thread or other thread/task calls jffs2_garbage_collect_pass, and then operates sb->s_root by jffs2_iget.meanwhile, the main task accesing sb->s_root. a global lock for each JFFS2 instance can't work.
- 14:45 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) closed by Sebastian Huber
- invalid: Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.
- 14:43 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) closed by Sebastian Huber
- invalid: Yes, the f->sem is an empty structure, it is not initialized, it is not used, locked or whatever in RTEMS. This is intentional and not a bug. I repeat: The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance.
- 14:42 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) reopened by chenjin_zhong
- 14:40 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) reopened by chenjin_zhong
- Replying to Sebastian Huber: > Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: > {{{#!c > static void rtems_jffs2_do_lock(struct super_block *sb) > { > rtems_recursive_mutex_lock(&sb->s_mutex); > } > > static void rtems_jffs2_do_unlock(struct super_block *sb) > { > rtems_recursive_mutex_unlock(&sb->s_mutex); > } > }}} I have compared it with Linux JFFS2. The peice of source code in Linux is as follows,As shown in black-body section, the f->sem is not be initialized and locked in RTEMS. […]
- 14:09 Changeset in rtems-central [45237bf] by Sebastian Huber <sebastian.huber@…>
- spec: Improve SMP-specific timecounter validation
- 12:28 Changeset in rtems-central [bcb0753] by Sebastian Huber <sebastian.huber@…>
- spec: Specify NTP support
- 11:06 Changeset in rtems-central [da36db3] by Sebastian Huber <sebastian.huber@…>
- spec: Specify _Timecounter_Tick_simple()
- 09:14 Changeset in rtems [5382f617]5 by Sebastian Huber <sebastian.huber@…>
- score: Add _Timecounter_Set_NTP_update_second() Allow the installation of an NTP update second handler which may be used by an NTP service. Update #4549.
- 09:14 Changeset in rtems [ffb8833d] by Sebastian Huber <sebastian.huber@…>
- score: Add _Timecounter_Set_NTP_update_second() Allow the installation of an NTP update second handler which may be used by an NTP service. Update #2348.
- 08:22 Changeset in rtems [34675587] by Sebastian Huber <sebastian.huber@…>
- kern_tc.c: Scaling/large delta recalculation This change is a slight performance optimization for systems with a slow 64-bit division. The th->th_scale and th->th_large_delta values only depend on the timecounter frequency and the th->th_adjustment. The timecounter frequency of a timehand only changes when a new timecounter is activated for the timehand. The th->th_adjustment is only changed by the NTP second update. The NTP second update is not done for every call of tc_windup(). Move the code block to recalculate the scaling factor and the large delta of a timehand to the new helper function recalculate_scaling_factor_and_large_delta(). Call recalculate_scaling_factor_and_large_delta() when a new timecounter is activated and a NTP second update occurred. MFC after: 1 week
- 08:22 Changeset in rtems [4f13092]5 by Sebastian Huber <sebastian.huber@…>
- kern_tc.c: Scaling/large delta recalculation This change is a slight performance optimization for systems with a slow 64-bit division. The th->th_scale and th->th_large_delta values only depend on the timecounter frequency and the th->th_adjustment. The timecounter frequency of a timehand only changes when a new timecounter is activated for the timehand. The th->th_adjustment is only changed by the NTP second update. The NTP second update is not done for every call of tc_windup(). Move the code block to recalculate the scaling factor and the large delta of a timehand to the new helper function recalculate_scaling_factor_and_large_delta(). Call recalculate_scaling_factor_and_large_delta() when a new timecounter is activated and a NTP second update occurred. MFC after: 1 week
- 05:20 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
- 05:20 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
- 05:19 Ticket #4536 (acess JFFS2 sb->s_root) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
- 05:19 Ticket #4535 (acess JFFS2 sb->s_root question) closed by Sebastian Huber
- invalid: Thanks for your interest in the RTEMS port of JFFS2. If you have questions, then you could also ask them on the devel@… mailing list. The RTEMS port of JFFS2 does not use a file system internal locking. There is a global lock for each JFFS2 instance: […]
Note: See TracTimeline
for information about the timeline view.
