![[RTEMS Logo]](/images/logo.png){kind=logo}
Timeline
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: […]
10/27/21:
- 15:13 Ticket #4538 (mutex is not initilaized in jffs2_read_inode) created by chenjin_zhong
- HI, I have found when call jffs2_read_inode to read inode. the f->sem …
- 14:59 Ticket #4537 (mutex is not initilaized in jffs2_new_inode) created by chenjin_zhong
- HI, I have found when call jffs2_new_inode to create inode. the f->sem …
- 14:47 Ticket #4536 (acess JFFS2 sb->s_root) created by chenjin_zhong
- Hi, I have found when access global structure without mutex or …
- 14:34 Ticket #4535 (acess JFFS2 sb->s_root question) created by chenjin_zhong
- Hi, I have found when access global structure without mutex or …
- 14:12 Changeset in rtems-central [94ed8b1] by Sebastian Huber <sebastian.huber@…>
- spec: Fix sporadic test failure
- 10:59 Changeset in rtems [240a1f7] by Sebastian Huber <sebastian.huber@…>
- score: Introduce CPU budget operations This patch set replaces the CPU budget algorithm enumeration with a set of CPU budget operations which implement a particular CPU budget algorithm. This helps to hide the CPU budget algorithm implementation details from the general thread handling. The CPU budget callouts are turned into CPU budget operations. This slightly reduces the size of the thread control block. All schedulers used the default scheduler tick implementation. The tick scheduler operation is removed and the CPU budget operations are directly used in _Watchdog_Tick() if the executing thread uses a CPU budget algorithm. This is performance improvement for all threads which do not use a CPU budget algorithm (default behaviour).
- 07:46 Changeset in rtems [75527ef3] by Sebastian Huber <sebastian.huber@…>
- score: Optimize SMP EDF move to ready operation If a node is moved from the scheduled chain to the ready queue, then we know that it is the highest priority ready node. So, it can be prepended to the ready queue without doing any comparisons. Update #4531.
- 07:40 Ticket #4534 (SMP EDF scheduler violates priority group ordering) created by Sebastian Huber
- The SMP EDF scheduler supports one-to-one and one-to-all thread to …
- 06:48 Changeset in rtems [b9990b8d] by Sebastian Huber <sebastian.huber@…>
- score: Fix SMP EDF priority group ordering The SMP EDF scheduler supports one-to-one and one-to-all thread to processor affinities. The one-to-one thread to processor affinity introduces a constraint on the ordering of threads. The implementation uses one ready queue for threads which have a one-to-all affinity and one for each one-to-one affinity group. To order threads across the ready queues, a generation number is used. However, the approach to update the generation number each time a thread is inserted into a ready queue was wrong. The generation number needs to be updated only in the enqueue and enqueue scheduled operations where an insert priority is available. The scheduled chain needs to take the generation number into account. An example scenario which shows the bug is this. Let T be a high priority task affine to processor X. Let A be a lower priority task affine to processor X. Let B be a lower priority task with no affinity to a particular processor which executes on processor Y. Let B be in the same priority group than A and after A. Let T set the affinity to all processors. Now A (higher priority relative to B) should execute on X and T (high priority) should execute on Y. Close #4534.
- 06:35 Changeset in rtems [6d20f0c5] by Sebastian Huber <sebastian.huber@…>
- score: Add node to insert to Chain_Node_order This allows to use additional members of the nodes for comparision. Update #4534.
10/26/21:
- 14:35 Changeset in rtems-central [940bfeb0] by Sebastian Huber <sebastian.huber@…>
- spec: Update documentation
Note: See TracTimeline
for information about the timeline view.
