On 16/07/15 01:49, Saurabh Gadia wrote:
Hi,
Is there any explicit locking to avoid data races condition on members
of Thread_Control_struct in rtems? As for mutex we have ticket_lock
over its wait_queue in SMP architecture which can serve as explicit
locking in mutex. For thread I feel data
---
freebsd/sys/contrib/altq/altq/altq_subr.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/freebsd/sys/contrib/altq/altq/altq_subr.c
b/freebsd/sys/contrib/altq/altq/altq_subr.c
index 3ebd58d..cfa5c7e 100644
--- a/freebsd/sys/contrib/altq/altq/altq_subr.c
+++ b/freeb
---
freebsd/sys/contrib/altq/altq/altq_subr.c | 4
1 file changed, 4 insertions(+)
diff --git a/freebsd/sys/contrib/altq/altq/altq_subr.c
b/freebsd/sys/contrib/altq/altq/altq_subr.c
index 3ebd58d..fbbf589 100644
--- a/freebsd/sys/contrib/altq/altq/altq_subr.c
+++ b/freebsd/sys/contrib/altq/
From: Pavel Pisa
The update fixes breakage of TMS570 support after Alexander Krutwig
switch of RTEMS time read to timecounter mechanism
bsps: Convert clock drivers to use a timecounter
Mechanism to specify odd (non 1 Mhz) time base update frequencies
implemented after objections of Martin Galv
Signed-off-by: Premysl Houdek
---
c/src/lib/libbsp/arm/tms570/clock/clock.c | 34 ++---
.../lib/libbsp/arm/tms570/console/printk-support.c | 8 +-
c/src/lib/libbsp/arm/tms570/console/tms570-sci.c | 55
.../lib/libbsp/arm/tms570/include/system-clocks.h | 2 +-
c/src/lib/
Please attach any patches to tickets for 4.11 as it is entering
release and maintain mode.
On Wed, Jul 15, 2015 at 4:46 PM, Joel Sherrill
wrote:
> Premysel.. can you update the patch to account for this?
>
> It is OK to commit after that.
>
> --joel
>
> On 7/15/2015 3:01 PM, Martin Galvan wrote:
Thanks for following conventions. I guess this replaces the one Joel
sent yesterday?
On Thu, Jul 16, 2015 at 7:11 AM, Chris Johns wrote:
> ---
> freebsd/sys/contrib/altq/altq/altq_subr.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/freebsd/sys/contrib/altq/altq/altq_subr.c
> b/f
By attach, I should mean, refer or close the ticket in the commit
message. Thanks for opening the ticket already!
Gedare
On Thu, Jul 16, 2015 at 9:11 AM, Gedare Bloom wrote:
> Please attach any patches to tickets for 4.11 as it is entering
> release and maintain mode.
>
> On Wed, Jul 15, 2015 at
This is needed to follow the convention expected in nexus-devices.h
in the rtems-libbsd tree.
---
c/src/lib/libbsp/i386/pc386/include/bsp.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/i386/pc386/include/bsp.h
b/c/src/lib/libbsp/i386/pc386/include/b
Would you care to sweep the other bsp.h too?
On Thu, Jul 16, 2015 at 10:47 AM, Joel Sherrill
wrote:
> This is needed to follow the convention expected in nexus-devices.h
> in the rtems-libbsd tree.
> ---
> c/src/lib/libbsp/i386/pc386/include/bsp.h |4 ++--
> 1 files changed, 2 insertions(+),
Sure.
Should I do it before we branch?
--joel
On 7/16/2015 9:57 AM, Gedare Bloom wrote:
Would you care to sweep the other bsp.h too?
On Thu, Jul 16, 2015 at 10:47 AM, Joel Sherrill
wrote:
This is needed to follow the convention expected in nexus-devices.h
in the rtems-libbsd tree.
---
c/s
Up to you. If other BSPs might get libbsd support in 4.11 release, it
makes sense to do it now. Either way, you should open a ticket and
close it with the commit.
On Thu, Jul 16, 2015 at 11:01 AM, Joel Sherrill
wrote:
> Sure.
>
> Should I do it before we branch?
>
> --joel
>
> On 7/16/2015 9:57 A
These files were left after running the script in the previous patch.
---
c/src/lib/libbsp/arm/gba/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/nds/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/av5282/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/genmcf548x/include/bsp.h | 4 ++
This was done by the following script run from libbsp:
find * -name bsp.h | xargs -e grep -l "#ifndef.*_BSP_H" | while read b
do
echo $b
cpu=`echo $b | cut -d'/' -f1 | tr '[:lower:]' '[:upper:]' `
bsp=`echo $b | cut -d'/' -f2 | tr '[:lower:]' '[:upper:]' `
g="LIBBSP_${cpu}_${bsp}_BSP_H"
Hi
I am in the middle of a build sweep now with the tms570 patches
and my bsp.h changes. Once this finishes, I plan to push those
changes and cut the branch.
Speak now.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications R
Which qemu build are you using? And what qemu args for xilinx zynq?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
> On Jul 16, 2015, at 13:55 , Joel Sherrill wrote:
>
> I am in the middle of a build sweep now with the tms570 patches
> and my bsp.h changes. Once this finishes, I plan to push those
> changes and cut the branch.
>
> Speak now.
I have a two concerns but they’ll have to be fixed after the bran
On 7/16/2015 1:59 PM, Peter Dufault wrote:
On Jul 16, 2015, at 13:55 , Joel Sherrill wrote:
I am in the middle of a build sweep now with the tms570 patches
and my bsp.h changes. Once this finishes, I plan to push those
changes and cut the branch.
Speak now.
I have a two concerns but they
> On Jul 16, 2015, at 15:07 , Joel Sherrill wrote:
>
>>
>> - I was having NFS crashes regularly. I removed a pthread_mutex_trylock()
>> in an ISR (I assumed that was safe) while trying to make that ISR faster and
>> the NFS issues disappeared. I haven’t had time to go back to that either.
>
Yes I was looking for same present in Thread_Lock_control. I might some how
missed it while going through Thread_Control_struct. Thanks. Then as lock
is present then I suppose we might have certainly taken care of data race
conditions.
Thanks,
Saurabh Gadia
On Thu, Jul 16, 2015 at 12:19 AM, Seba
Hi,
I have just implemented global lock free nested mutex JPF model for SMP
arch also.
github JPF link:
https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.6-global-free
please review the model and give your feedback!!
Thanks,
Saurabh Gadia
___
On 16/07/2015 11:13 pm, Gedare Bloom wrote:
> Thanks for following conventions. I guess this replaces the one Joel
> sent yesterday?
Yes. I will push it.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 17/07/15 03:39, Cyrille Artho wrote:
Note that the lock only protects against direct accesses to the thread
priority. If other code relies on the fact that the change is still
current further down, then we may have an "atomicity race" (as it's
sometimes called) or causality problem (another na
23 matches
Mail list logo
