Re: Doubt regarding Thread_Control_struct in rtems

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

Re: [PATCH v2] Fix buiding for the i386.

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

Global lock free Nested Mutex JPF model

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 ___

Re: Doubt regarding Thread_Control_struct in rtems

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

Re: Near Last Call Before Branching 4.11

> 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. >

Re: Near Last Call Before Branching 4.11

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

Re: Near Last Call Before Branching 4.11

> 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

Re: GSoC 2015 RPi USB Support

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

Near Last Call Before Branching 4.11

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

[PATCH 1/2] Most bsp.h: Switch to LIBBSP_@CPU@_@BSP_FAMILY@_H for guard

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"

[PATCH 2/2] remaining bsp.h: Fix by hand to LIBBSP_@CPU@_@BSP_FAMILY@_BSP_H

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 ++

Re: [PATCH 1/2] pc386/.../bsp.h: Change include guard

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

Re: [PATCH 1/2] pc386/.../bsp.h: Change include guard

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

Re: [PATCH 1/2] pc386/.../bsp.h: Change include guard

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(+),

[PATCH 1/2] pc386/.../bsp.h: Change include guard

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

Re: [PATCH v2] Fix buiding for the i386.

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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:

[PATCH 1/3] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

[PATCH 3/3] bsp/tms570: source changes reflecting new headers.

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/

[PATCH v2] Fix buiding for the i386.

--- 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/

[PATCH] Fix buiding for the i386.

--- 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

Re: Doubt regarding Thread_Control_struct in rtems

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