For time being I am calculating it this way:
#define typeaddr(addr, type, member) \
(type *)((char *)(addr) - offsetof(type, member))
CORE_mutex_Control *the_mutex= typeaddr(holder-Wait.queue,
CORE_mutex_Control, Wait_queue);
Is there any other easy way? Like I guess we maintain objects so is
Hi,
For a given thread waiting on a mutex, how can we extract the mutex_control
on which this thread is waiting? For example in Thread_Change_priority().
So do the thread_control structure has any reference to mutex on which it
is blocked?
Thanks,
Saurabh Gadia
On Thu, Aug 13, 2015 at 4:57 AM, Saurabh Gadia ga...@usc.edu wrote:
For time being I am calculating it this way:
#define typeaddr(addr, type, member) \
(type *)((char *)(addr) - offsetof(type, member))
If you need this, use RTEMS_CONTAINER_OF macro
CORE_mutex_Control *the_mutex=
On Wed, Aug 12, 2015 at 5:15 PM, Rohini Kulkarni krohini1...@gmail.com wrote:
Hi,
It would be great if somebody can help here.
[1] How are the mailbox registers available for each core of Pi2 to be used.
[2] Another thing is that I don't know which registers of Pi 1 are available
for Pi2 as
Hi,
I have implemented uniprocessor model of nested mutex problem in rtems. its
still in basic form. I tried to multiplex it with the existing solution but
was finding hard time. To push ahead, I decided to have separate functions
for uniprocessor and SMP(kept default behavior) and with your
Daniel,
The release has (unofficially) happened on rtems.git/4.11 branch, from
which master is slowly diverging. Any patches you want applied before
the official release need to be (1) associated with a ticket on Trac,
and (2) apply to both the 4.11 and master branches.
Gedare
On Wed, Aug 12,
Saurabh,
Please pull from rtems.git again, create a new branch from 'master',
and apply your changes to the branch. It's too hard to review code
that is not all by itself on a branch.
Gedare
On Thu, Aug 13, 2015 at 5:28 AM, Saurabh Gadia ga...@usc.edu wrote:
Hi,
I have implemented
On Thu, Aug 13, 2015 at 8:04 AM, Ketul Shah ketulshah1...@gmail.com wrote:
Hi Andre,
Great API and happy to know that it is merged with main line.
Eventually I implemented GPIO driver for BBB using this API. After debugging
for rtems_gpio_get_value() on BBB I found the following bug.
For
Can you please print the output from spsem04 without strict-order
enabled? (Or, without your patches to fix it?)
On Thu, Aug 13, 2015 at 6:31 AM, Saurabh Gadia ga...@usc.edu wrote:
Hi,
To validate spsem03 test case I created a new test case by modifying
spsem02. Below is the description of
On 13-08-2015 14:51, Ketul Shah wrote:
Hi Andre,
Thanks for the reply.
On 13 August 2015 at 19:13, André Marques
andre.lousa.marq...@gmail.com mailto:andre.lousa.marq...@gmail.com
wrote:
Hello Ketul,
On 13-08-2015 13:04, Ketul Shah wrote:
Hi Andre,
Great API and
Hello Andre,
I created a ticket https://devel.rtems.org/ticket/2390 . Please make the
necessary changes.
Thanks.
Cheers,
Ketul
On 13 August 2015 at 19:38, André Marques andre.lousa.marq...@gmail.com
wrote:
On 13-08-2015 14:51, Ketul Shah wrote:
Hi Andre,
Thanks for the reply.
On 13
Hi,
I have created a new branch for uniprocessor solution of priority inversion
problem caused by nested mutex behavior.
link: https://github.com/saurabhgadia4/rtems/tree/nested-mutex
test case results:
How can we get mutex-queue.priority_before data structure without having
the mutex structure. We need that to change the priority_before for every
acquired mutex by a thread to ensure that there is proper stepdown of
priority. We just need to have mutex to get the start point of the
chain_control
On 14/08/2015 6:34 am, Daniel Gutson wrote:
I'd recommend a gcc plugin that generates your annotations;
There is a Python framework for plugins to help make things easier ...
http://gcc-python-plugin.readthedocs.org/en/latest/index.html
Chris
___
On August 13, 2015 3:34:12 PM CDT, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
I'd recommend a gcc plugin that generates your annotations; otherwise,
dig into gcov in order to parse a .gcno file.
Covoar already produces gcov files. A previous gsoc student did that. This was
a
On August 13, 2015 5:38:24 PM CDT, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
El 13/8/2015 19:35, Joel Sherrill joel.sherr...@oarcorp.com
escribió:
On August 13, 2015 3:34:12 PM CDT, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
I'd recommend a gcc plugin that
I see, it is the list being passed, not the mutex_control. I misread
something earlier.
It may be acceptable to store a pointer to this list into the
Thread_Control somewhere if that will simplify the interface and not
complicate the implementation by too much. But I haven't given this
too much
---
c/src/lib/libbsp/arm/shared/mminit.c | 17 +++--
c/src/lib/libbsp/shared/include/mm.h |5 -
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..f2617f8 100644
---
El 13/8/2015 19:35, Joel Sherrill joel.sherr...@oarcorp.com escribió:
On August 13, 2015 3:34:12 PM CDT, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
I'd recommend a gcc plugin that generates your annotations; otherwise,
dig into gcov in order to parse a .gcno file.
Covoar
On Thu, Aug 13, 2015 at 7:31 PM, Cyrille Artho cyrille.ar...@gmail.com wrote:
Hi Gedard,
The CORE_mutex_order_list in the thread priority update functions is
needed to step down the priority in the right way upon unlocking.
Currently these functions are only used internally.
If you'd like a
Yeah. I am working now on developing a validate method to point out bad and
good results. And documentation seems to be super important for now because
I feel that logic is correct just some semantics based on above discussion
will change.
On Thursday, August 13, 2015, Gedare Bloom
---
c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am |4 +++
.../arm/realview-pbx-a9/startup/bspstarthooks.c| 27 ++--
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
---
c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am |4 +++
.../libbsp/arm/xilinx-zynq/startup/bspstartmmu.c | 27 ++--
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
On Thu, Aug 13, 2015 at 6:55 PM, Saurabh Gadia ga...@usc.edu wrote:
How can we get mutex-queue.priority_before data structure without having
the mutex structure. We need that to change the priority_before for every
acquired mutex by a thread to ensure that there is proper stepdown of
priority.
Saurabh,
Remove the commit Updated the motivation for creating the new
branch, don't add the .tags files, and don't add the .m4 changes that
are not related to your project.
Switch to using RTEMS_CONTAINER_OF macro and remove the typeaddr one.
coremutexseize.c : remove the modification where
I am looking for something that processes the source code at compile time.
I need this information to map branches from execution traces to conditions
within the source code. With this information it will be possible to
analyze source coverage metrics as decision coverage or MCDC.
Daniel Gutson
This still doesn't apply for me.
Did you pull the latest changes and rebase?
--joel
On 8/12/2015 5:08 PM, YANG QIAO wrote:
From: YANG Qiao yangqiao0...@me.com
---
c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 4 ++
c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h | 32
Hi all!
I am working on a tool to analyze source code coverage for RTEMS.
Currently I am looking for a tool to annotate source code such that I can
extract information about statements and conditions that affect the control
flow of a program.
A similar tool exists for Ada programs. They call this
1) Are you looking for something statically processed (i.e. at compile
time) or at runtime? (such as gcov)
2) Are you looking for a way to add _your_ annotations, or a way to
_extract_ information?
In any case, the best way I can think of is with a gcc plugin.
Have you seen gcc's -ftest-coverage
I'd recommend a gcc plugin that generates your annotations; otherwise,
dig into gcov in order to parse a .gcno file.
On Thu, Aug 13, 2015 at 5:09 PM, Hermann Felbinger
hermann19...@gmail.com wrote:
I am looking for something that processes the source code at compile time. I
need this
On 8/13/2015 2:06 PM, Hermann Felbinger wrote:
Hi all!
I am working on a tool to analyze source code coverage for RTEMS.
Currently I am looking for a tool to annotate source code such that I can
extract information about statements and conditions that affect the control
flow of a program.
A
On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
---
-BSP_START_DATA_SECTION static const arm_cp15_start_section_config
-zynq_mmu_config_table[] = {
+BSP_START_DATA_SECTION const arm_cp15_start_section_config
+arm_cp15_start_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
On August 13, 2015 7:15:08 PM CDT, Chris Johns chr...@rtems.org wrote:
On 14/08/2015 6:34 am, Daniel Gutson wrote:
I'd recommend a gcc plugin that generates your annotations;
There is a Python framework for plugins to help make things easier ...
Hi,
Following is the result of spsem04 test without the patch:
*** BEGIN OF TEST SPSEM 4 ***
init: S0 created
init: S1 created
init: TA01 created with priority 36
init: TA02 created with priority 34
init: TA03 created with priority 32
TA01: started with priority 36
TA01: priority 36,
Thanks. Would it be possible for you to turn the failure cases into
real test failures? In other words, add some logic to detect the
priority inversion and abort the test?
Gedare
On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia ga...@usc.edu wrote:
Hi,
Following is the result of spsem04 test
That is how we were doing in JPF. The validate method was triggered after
every release of mutex by any thread and we would check for all the waiting
threads on mutex's held by the holder. And if it finds a thread with higher
priority blocked then it would panic or give assertion failure.
Thanks,
Daniel,
Unknown deadline right now. Probably whenever Joel can get around to
it! Realistically, we can create a bugfix dot release anytime after
the release subject to user demand. So, even if you miss the 4.11.0
release with your patches, we can cut a 4.11.1 after applying the
patches if you
El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu escribió:
Daniel,
Unknown deadline right now. Probably whenever Joel can get around to
it! Realistically, we can create a bugfix dot release anytime after
the release subject to user demand. So, even if you miss the 4.11.0
release with your
38 matches
Mail list logo
