[PATCH] Added APA terms in glossary

[Richi Dubey]

---
 c-user/glossary.rst | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 86350a8..7442388 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -1,5 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
 .. Copyright (C) 2017, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 1998 On-Line Applications Research Corporation (OAR)
 
@@ -16,6 +17,15 @@ Glossary
 A term used to describe an object which has been created by an
 application.
 
+APA
+This term is an acronym for Arbitrary Processor Affinity.  APA
+schedulers allow a thread to have an arbitrary affinity to a
+processor set, rather than a restricted mapping to only one
+processor of the set or the ability to run on all processors of
+the set. 
+
+It has two variants, :term:`Weak APA` and :term:`Strong APA`.
+
 aperiodic task
 A task which must execute only at irregular intervals and has only a 
soft
 deadline.
@@ -777,6 +787,20 @@ Glossary
 :term:`return value` to indicate a successful operation or error
 conditions.
 
+Strong APA
+Strong APA is a specialization of :term:`APA`. 
+Schedulers which implement strong APA recursively search for a
+processor in the :term:`thread`'s affinity set, whenever a thread
+becomes ready for execution, followed by the processors in the
+affinity set of threads that are assigned the processor in the
+ready thread's affinity set. This is done to find a thread to
+processor mapping that does not violate the priority ordering and
+to provide a thread to processor mapping with a higher total
+priority of the threads allocated a processor.
+Similar analysis is done when a thread blocks.  
+
+See also :cite:`Cerqueira:2014:LPA`.
+
 suspend
 A term used to describe a task that is not competing for the CPU 
because it
 has had a ``rtems_task_suspend`` directive.
@@ -905,6 +929,17 @@ Glossary
 Message queues, regions, and semaphores have a wait queue associated 
with
 them.
 
+Weak APA
+Weak APA is a specialization of :term:`APA`.  
+It refers to Linux's push and pull implementation of APA model.
+When a :term:`thread` becomes ready for execution, it is
+allocated a processor if there is an idle processor, or if a
+processor is executing a lower priority thread in its affinity
+set. Unlike :term:`Strong APA`, no thread is migrated from its
+processor to find a thread to processor mapping.
+
+See also :cite:`Cerqueira:2014:LPA`.
+
 YAML
 This term is an acronym for `YAML Ain't Markup Language 
`_.
 
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Added APA terms in glossary

[Richi Dubey]

---
 c-user/glossary.rst | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 86350a8..63a4728 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -1,5 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
 .. Copyright (C) 2017, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 1998 On-Line Applications Research Corporation (OAR)
 
@@ -16,6 +17,14 @@ Glossary
 A term used to describe an object which has been created by an
 application.
 
+APA
+This term is an acronym for Arbitrary Processor Affinity.  
+APA schedulers allow a thread to have an arbitrary affinity to a
+processor set, rather than a restricted mapping to only one processor
+of the set or the ability to run on all processors of the set. 
+
+It has two variants, :term:`Weak APA` and :term:`Strong APA`.
+
 aperiodic task
 A task which must execute only at irregular intervals and has only a 
soft
 deadline.
@@ -777,6 +786,20 @@ Glossary
 :term:`return value` to indicate a successful operation or error
 conditions.
 
+Strong APA
+Strong APA is a specialization of :term:`APA`. 
+Schedulers which implement strong APA recursively search for a
+processor in the :term:`thread`'s affinity set, whenever a thread
+becomes ready for execution, followed by the processors in the
+affinity set of threads that are assigned the processor in the
+ready thread's affinity set. This is done to find a thread to
+processor mapping that does not violate the priority ordering and
+to provide a thread to processor mapping with a higher total
+priority of the threads allocated a processor.
+Similar analysis is done when a thread blocks.  
+
+See also :cite:`Cerqueira:2014:LPA`.
+
 suspend
 A term used to describe a task that is not competing for the CPU 
because it
 has had a ``rtems_task_suspend`` directive.
@@ -905,6 +928,17 @@ Glossary
 Message queues, regions, and semaphores have a wait queue associated 
with
 them.
 
+Weak APA
+Weak APA is a specialization of :term:`APA`.  
+It refers to Linux's push and pull implementation of APA model.
+When a :term:`thread` becomes ready for execution, it is
+allocated a processor if there is an idle processor, or if a
+processor is executing a lower priority thread in its affinity
+set. Unlike :term:`Strong APA`, no thread is migrated from its
+processor to find a thread to processor mapping.
+
+See also :cite:`Cerqueira:2014:LPA`.
+
 YAML
 This term is an acronym for `YAML Ain't Markup Language 
`_.
 
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added APA terms in glossary

[Richi Dubey]

Hi,
Please ignore the first patch as the formatting in it looks a little
uneven. Thanks!

On Sun, Jun 21, 2020 at 2:48 PM Richi Dubey  wrote:

> ---
>  c-user/glossary.rst | 34 ++
>  1 file changed, 34 insertions(+)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 86350a8..63a4728 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -1,5 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> +.. Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
>  .. Copyright (C) 2017, 2019 embedded brains GmbH (
> http://www.embedded-brains.de)
>  .. Copyright (C) 1988, 1998 On-Line Applications Research Corporation
> (OAR)
>
> @@ -16,6 +17,14 @@ Glossary
>  A term used to describe an object which has been created by an
>  application.
>
> +APA
> +This term is an acronym for Arbitrary Processor Affinity.
> +APA schedulers allow a thread to have an arbitrary affinity to a
> +processor set, rather than a restricted mapping to only one
> processor
> +of the set or the ability to run on all processors of the set.
> +
> +It has two variants, :term:`Weak APA` and :term:`Strong APA`.
> +
>  aperiodic task
>  A task which must execute only at irregular intervals and has
> only a soft
>  deadline.
> @@ -777,6 +786,20 @@ Glossary
>  :term:`return value` to indicate a successful operation or error
>  conditions.
>
> +Strong APA
> +Strong APA is a specialization of :term:`APA`.
> +Schedulers which implement strong APA recursively search for a
> +processor in the :term:`thread`'s affinity set, whenever a thread
> +becomes ready for execution, followed by the processors in the
> +affinity set of threads that are assigned the processor in the
> +ready thread's affinity set. This is done to find a thread to
> +processor mapping that does not violate the priority ordering and
> +to provide a thread to processor mapping with a higher total
> +priority of the threads allocated a processor.
> +Similar analysis is done when a thread blocks.
> +
> +See also :cite:`Cerqueira:2014:LPA`.
> +
>  suspend
>  A term used to describe a task that is not competing for the CPU
> because it
>  has had a ``rtems_task_suspend`` directive.
> @@ -905,6 +928,17 @@ Glossary
>  Message queues, regions, and semaphores have a wait queue
> associated with
>  them.
>
> +Weak APA
> +Weak APA is a specialization of :term:`APA`.
> +It refers to Linux's push and pull implementation of APA model.
> +When a :term:`thread` becomes ready for execution, it is
> +allocated a processor if there is an idle processor, or if a
> +processor is executing a lower priority thread in its affinity
> +set. Unlike :term:`Strong APA`, no thread is migrated from its
> +processor to find a thread to processor mapping.
> +
> +See also :cite:`Cerqueira:2014:LPA`.
> +
>  YAML
>  This term is an acronym for `YAML Ain't Markup Language <
> https://yaml.org/>`_.
>
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Adding APA terms to glossary

[Richi Dubey]

Hi,

Thanks for another review and your patience. I've sent in a patch with the
suggested changes. Please let me know if it looks okay.


On Fri, Jun 19, 2020 at 4:46 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Richi,
>
> thanks for the update, we are getting closer to the final version.
>
> On 19/06/2020 11:49, Richi Dubey wrote:
> > ---
> >   c-user/glossary.rst | 31 +++
> >   1 file changed, 31 insertions(+)
> >
> > diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> > index 86350a8..691ba52 100644
> > --- a/c-user/glossary.rst
> > +++ b/c-user/glossary.rst
> > @@ -1,5 +1,6 @@
> >   .. SPDX-License-Identifier: CC-BY-SA-4.0
> >
> > +.. Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
> >   .. Copyright (C) 2017, 2019 embedded brains GmbH (
> http://www.embedded-brains.de)
> >   .. Copyright (C) 1988, 1998 On-Line Applications Research Corporation
> (OAR)
> >
> > @@ -16,6 +17,13 @@ Glossary
> >   A term used to describe an object which has been created by an
> >   application.
> >
> > +APA
> > +This term is an acronym for Arbitrary Processor Affinity.
> > +APA schedulers allow a thread to have an arbitrary affinity to
> > +a processor set, rather than a restricted mapping to only one
> > +processor of the set or the ability to run on all processors of
> > +the set. It has two variants, :term:`Weak APA` and
> :term:`Strong APA`
> Looks good, except the missing dot to end the last sentence. Please try
> the vim "gq" to format the text.
> > +
> >   aperiodic task
> >   A task which must execute only at irregular intervals and has
> only a soft
> >   deadline.
> > @@ -777,6 +785,19 @@ Glossary
> >   :term:`return value` to indicate a successful operation or
> error
> >   conditions.
> >
> > +Strong APA
> > +Strong APA is a specialization of :term:`APA`.
> > +Whenever a :term:`thread` becomes ready for execution,
> schedulers which
> > +implement strong APA recursively search for a processor in the
> thread's
> > +affinity set, followed by the processors in the affinity set of
> threads
> > +that are assigned the processor present in the ready thread's
> affinity set.
> > +This is done to find a thread to processor mapping that does
> not violate the
> > +priority ordering and to provide a schedule with a higher total
> priority of
> Sorry for being pedantic, but please keep in mind that RTEMS users
> interested in this stuff may not have read many scheduler papers. They
> may ask what "a schedule" is.
> > +the threads scheduled.
> > +Similar analysis is done when a thread finishes its execution.
> "finishes its execution" -> "blocks".
> > +
> > +See also :cite:`Cerqueira:2014:LPA`.
> > +
> >   suspend
> >   A term used to describe a task that is not competing for the
> CPU because it
> >   has had a ``rtems_task_suspend`` directive.
> > @@ -905,6 +926,16 @@ Glossary
> >   Message queues, regions, and semaphores have a wait queue
> associated with
> >   them.
> >
> > +Weak APA
> > +Weak APA is a specialization of :term:`APA`. This refers to
> Linux's push and
> > +pull implementation of APA model. On the arrival of a thread,
> Please avoid this "arrival", use a phrase like "Whenever a
> :term:`thread` becomes ready for execution" like above.
> > the thread is
> > +scheduled when a processor in its affinity set is idle or a
> processor in its
> > +affinity set is executing a thread which is at a lower priority.
> > +Unlike :term:`Strong APA`, no thread is migrated from its
> processor to find
> > +a thread to processor mapping.
> > +
> > +See also :cite:`Cerqueira:2014:LPA`.
> > +
> >   YAML
> >   This term is an acronym for `YAML Ain't Markup Language <
> https://yaml.org/>`_.
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Build FreeBSD: FAILED devel/qemu4 on x86_64-freebsd12.1 (glib-2.46.2-x86_64-freebsd12.1-1)

[Chris Johns]

> On 21 Jun 2020, at 2:15 pm, Joel Sherrill  wrote:
> 
> Build failure on FreeBSD
> 

Have you tripped over the revoke issue in a session somehow...

https://bugs.python.org/issue32849

?

I do not see this as a bug in the RSB or the qemu4 config.

Chris___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: m2006-2 Linux Build Sweep Feedback

[Chris Johns]

> On 21 Jun 2020, at 12:48 am, Joel Sherrill  wrote:
> 
> Hi
> 
> The m2006-2 candidate passed more of the build sweep steps than any of the 
> other candidates.

Great. I will branch the repos tomorrow. 

Thank you for all your testing and reports. They are really helpful and 
important. 

> The bsp builder sweep of all BSPs and many (1700+) configurations has the 
> normal 6 GCC induced epiphany failures. All but one of the BSP bsets built. 
> atsamv failed:
> 
> https://lists.rtems.org/pipermail/build/2020-June/015864.html 
> 
> Looks like libbsd failed to build for that BSP with this:
> 
> ===
> [1875/1925] Linking build/arm-rtems5-atsamv-default/epoch01.exe
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2047ab60 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
> 
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2053f9a0 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
> 
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2053f9a0 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
> 
> Waf: Leaving directory 
> `/home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/rtems-libbsd-d38dbbe18e5315bf69a7c3916d71ef3838d4c20d-x86_64-linux-gnu-1/rtems-libbsd-5.0.0-m2006-2/build/arm-rtems5-atsamv-default'
> Build failed
> ===
> 
> No one may read this far but this failure and Jan's Pi2 testing failure 
> appear to be the hurdles now.

That is a shame. Fixes are welcome. 

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Error when running make in leon3 bsp to make the testsuites

[Richi Dubey]

Hi,

I am getting the following error when running make in leon3 with smp
enabled bsp:

Making all-am in smptests
make[3]: Entering directory
'/home/richi/quick-start/build/smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests'
Makefile:2365: smpstrongapa01/.deps/smpstrongapa01-init.Po: No such file or
directory
make[3]: *** No rule to make target
'smpstrongapa01/.deps/smpstrongapa01-init.Po'.  Stop.
make[3]: Leaving directory
'/home/richi/quick-start/build/smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests'
Makefile:663: recipe for target 'smptests' failed
make[2]: *** [smptests] Error 2
make[2]: Leaving directory
'/home/richi/quick-start/build/smp-leon3/sparc-rtems5/c/leon3/testsuites'
Makefile:1222: recipe for target 'testsuites' failed
make[1]: *** [testsuites] Error 2
make[1]: Leaving directory
'/home/richi/quick-start/build/smp-leon3/sparc-rtems5/c/leon3'
Makefile:716: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

This has been happening after I changed something in smpstrongapa01/init.c
and now when I undid my changes by doing git reset and being even with the
master branch, I am still getting the same error.

Can someone please tell me what might be wrong?

Thanks,
Richi.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Build FreeBSD: FAILED devel/qemu4 on x86_64-freebsd12.1 (glib-2.46.2-x86_64-freebsd12.1-1)

[Joel Sherrill]

On Sun, Jun 21, 2020, 6:05 AM Chris Johns  wrote:

>
> On 21 Jun 2020, at 2:15 pm, Joel Sherrill  wrote:
>
> Build failure on FreeBSD
>
>
> Have you tripped over the revoke issue in a session somehow...
>
> https://bugs.python.org/issue32849
>
> ?
>
> I do not see this as a bug in the RSB or the qemu4 config
>
I probably did. When it finishes I will try it again

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: m2006-2 Linux Build Sweep Feedback

[Alan Cudmore]

For the Pi2 SMP:
I started looking at this a while ago. If I remember correctly, Pi2
SMP worked on QEMU. I have an original Pi2 that it fails on (using
smp01.exe). I dont have a really good way to debug on the hardware, so
I was going down the path of using printk statements to figure out
where it was hanging. The console log below shows how far I was able
to get.
It looks like it's in _CPU_SMP_Processor_event_receive waiting for the
2nd CPU to change state.
If anyone has clues of where to look next, I can try a few changes out.

Alan


RTEMS RPi 2B 1.1 (1GB) [00a21041]
in _SMP_Handler_initialize
in _SMP_Handler_initialize, max processors = 4
in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
in _CPU_SMP_Initialize
in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
in _SMP_Handler_initialize - calling _SMP_Start_processors
In _SMP_Start_processors
In _SMP_Start_processors - index = 0
In _SMP_Start_processors - cpu_index = self, so started already
In _SMP_Start_processors - index = 1
In _SMP_Start_processors - calling _CPU_SMP_Start_processor
in _CPU_SMP_Start_processor : cpu_index = 1
in _CPU_SMP_Start_processor - call
_Per_CPU_State_wait_for_non_initial_state - bool started = 0
in Per_CPU_State_wait_for_non_initial_state index = 1, timeout = 0
 CPU state before = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop
in Per_CPU_State_wait_for_non_initial_state - after
_CPU_SMP_Processor_event_receive in while loop
 CPU state  after = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop

On Sun, Jun 21, 2020 at 7:09 AM Chris Johns  wrote:
>
>
> On 21 Jun 2020, at 12:48 am, Joel Sherrill  wrote:
>
> Hi
>
> The m2006-2 candidate passed more of the build sweep steps than any of the 
> other candidates.
>
>
> Great. I will branch the repos tomorrow.
>
> Thank you for all your testing and reports. They are really helpful and 
> important.
>
> The bsp builder sweep of all BSPs and many (1700+) configurations has the 
> normal 6 GCC induced epiphany failures. All but one of the BSP bsets built. 
> atsamv failed:
>
> https://lists.rtems.org/pipermail/build/2020-June/015864.html
>
> Looks like libbsd failed to build for that BSP with this:
>
> ===
> [1875/1925] Linking build/arm-rtems5-atsamv-default/epoch01.exe
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2047ab60 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2053f9a0 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
>  cannot move location counter backwards (from 2053f9a0 to 
> 2045f000)
> collect2: error: ld returned 1 exit status
>
> Waf: Leaving directory 
> `/home/joel/rtems-cron-5.0.0-m2006-2/rtems-source-builder-5.0.0-m2006-2/rtems/build/rtems-libbsd-d38dbbe18e5315bf69a7c3916d71ef3838d4c20d-x86_64-linux-gnu-1/rtems-libbsd-5.0.0-m2006-2/build/arm-rtems5-atsamv-default'
> Build failed
> ===
>
> No one may read this far but this failure and Jan's Pi2 testing failure 
> appear to be the hurdles now.
>
>
> That is a shame. Fixes are welcome.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: Release snapshot 5.0.0-m2006-2 available

[Heinz Junkes]

I forgot to send it to rtems-devel...


> Begin forwarded message:
> 
> From: junkes 
> Subject: Re: Release snapshot 5.0.0-m2006-2 available
> Date: 21. June 2020 at 13:53:35 CEST
> To: Chris Johns 
> 
> Hello Chris,
> thanks for the release snapshot. It all looks very good already.
> I have tried it for xilinx_zynq_a9_qemu.
> configuration:
> $ ../../rtems/configure \
>> --prefix=$HOME/development/rtems/5 \
>> --enable-maintainer-mode \
>> --enable-posix \
>> --enable-cxx \
>> --target=arm-rtems5 \
>> --enable-rtemsbsp=xilinx_zynq_a9_qemu \
>> --enable-tests
> 
> rtems-test --rtems-bsp=xilinx_zynq_a9_qemu 
> --rtems-tools=$HOME/development/rtems/5 .
> 
> returns the following errors:
> 
> RTEMS Testing - Tester, 5.0.not_released
> Command Line: /Users/junkes/development/rtems/5/bin/rtems-test 
> --rtems-bsp=xilinx_zynq_a9_qemu 
> --rtems-tools=/Users/junkes/development/rtems/5 .
> Host: Darwin h.fritz.box 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 
> 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
> Python: 3.7.3 (default, Apr 24 2020, 18:51:23) [Clang 11.0.3 
> (clang-1103.0.32.62)]
> Host: Darwin-19.5.0-x86_64-i386-64bit (Darwin h.fritz.box 19.5.0 Darwin 
> Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; 
> root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 i386)
> [  1/599] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: dhrystone.exe
> [  3/599] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: whetstone.exe
> [  2/599] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: linpack.exe
> ...
> [125/599] p:115 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: rbheap01.exe
> [129/599] p:119 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: sha.exe
> [126/599] p:118 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: record01.exe
> Result: failed Time: 0:00:01.007355 record01.exe
> =>  run: qemu-system-arm -no-reboot -nographic -net none -serial null -serial 
> mon:stdio -M xilinx-zynq-a9 -m 256M -kernel 
> ./arm-rtems5/c/xilinx_zynq_a9_qemu/testsuites/libtests/record01.exe
> ] qemu-system-arm: warning: nic cadence_gem.0 has no peer
> ] qemu-system-arm: warning: nic cadence_gem.1 has no peer
> ]
> ]
> =>  test start: RECORD 1
> ] *** BEGIN OF TEST RECORD 1 ***
> ] *** TEST VERSION: 5.0.0-m2006-2
> ] *** TEST STATE: EXPECTED_PASS
> ] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> ] *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5.0.0-m2006-2, Newlib 7947581)
> ] ../../../../../../../rtems/c/src/../../testsuites/libtests/record01/init.c: 
> 633 hs == HEADER_LAST || items[0].event == hs_to_ev(hs)
> ]
> ] *** FATAL ***
> ] fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> ] fatal code: 0 (0x)
> ] RTEMS version: 5.0.0-m2006-2
> ] RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5.0.0-m2006-2, Newlib 7947581)
> ] executing thread ID: 0x08a010001
> ] executing thread name: UI1
> ]
> [127/599] p:118 f:0   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: record02.exe
> [130/599] p:120 f:1   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: shell01.exe
> [131/599] p:120 f:1   u:2   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: sparsedisk01.exe
> ...
> [168/599] p:155 f:1   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx11.exe
> [169/599] p:156 f:1   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx12.exe
> [170/599] p:157 f:1   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx13.exe
> [171/599] p:157 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx14.exe
> [173/599] p:160 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx16.exe
> [172/599] p:160 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psx15.exe
> [174/599] p:160 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaio01.exe
> [176/599] p:163 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaio03.exe
> [175/599] p:163 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxaio02.exe
> [177/599] p:163 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxalarm01.exe
> [179/599] p:166 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxautoinit02.exe
> [178/599] p:166 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxautoinit01.exe
> [180/599] p:166 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxbarrier01.exe
> [181/599] p:169 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxcancel.exe
> [182/599] p:169 f:2   u:4   e:1   I:0   B:3   t:0   i:0   W:0   | 
> arm/xilinx_zynq_a9_qemu: psxcancel01.ex

[5.0.0-m2006-2] Test compilation error in riscv bsps

[Jan.Sommer]

Hello,

I just tried to compile some riscv bsps with tests enabled and got a compile 
time error for the dl06 test.
I tried with griscv and rv32imac with the following configure:

../rtems-5.0.0-m2006-2/configure --target=riscv-rtems5 --prefix../install/bsps 
--disable-networking --enable-tests --enable-rtemsbsp=griscv

I got the following error:

rtems-ld -r /localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv \
  -C riscv-rtems5-gcc -c "-march=rv32imafd -mabi=ilp32d" \
  -O rap -b dl06.pre -e rtems_main -s \
  -o dl06.rap dl06-o1.o dl06-o2.o -lm
error: rap::object: Section index '0' not found: dl06-o1.o
Makefile:8479: recipe for target 'dl06.rap' failed
make[5]: *** [dl06.rap] Error 10
make[5]: Leaving directory 
'/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv/testsuites/libtests'
Makefile:663: recipe for target 'libtests' failed
make[4]: *** [libtests] Error 2
make[4]: Leaving directory 
'/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv/testsuites'
Makefile:1222: recipe for target 'testsuites' failed
make[3]: *** [testsuites] Error 2
make[3]: Leaving directory 
'/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv'
Makefile:716: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
'/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv'
Makefile:289: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
'/localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c'
Makefile:410: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
make all  112,71s user 27,01s system 102% cpu 2:16,13 total

It is the first time I tried anything with riscv, so I might have done 
something wrong.

Best regards,

   Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Simulation and Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help understanding the function Scheduler_SMP_Allocate_processor_lazy

[Richi Dubey]

Hi,

I'm sorry, I did not! Thanks for the suggestions. I'll go through its
calling functions, and the functions it calls.



On Sat, Jun 20, 2020 at 7:51 PM Gedare Bloom  wrote:

> On Sat, Jun 20, 2020 at 6:12 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > I've been learning how SMP scheduler word in RTEMS and I came across the
> following function definition:
> >
> 
> >
> > /**
> >  * @brief Allocates the cpu for the scheduled thread.
> >  *
> >  * Attempts to prevent migrations but does not take into account
> affinity.
> >  *
> >  * @param context The scheduler context instance.
> >  * @param scheduled The scheduled node that should be executed next.
> >  * @param victim If the heir is this node's thread, no processor is
> allocated.
> >  * @param[in, out] victim_cpu The cpu to allocate.
> >  */
> >
> >  static inline void _Scheduler_SMP_Allocate_processor_lazy(
> >   Scheduler_Context *context,
> >   Scheduler_Node*scheduled,
> >   Scheduler_Node*victim,
> >   Per_CPU_Control   *victim_cpu
> > )
> > {
> >   Thread_Control *scheduled_thread = _Scheduler_Node_get_user( scheduled
> );
> >   Thread_Control *victim_thread = _Scheduler_Node_get_user( victim );
> >   Per_CPU_Control *scheduled_cpu = _Thread_Get_CPU( scheduled_thread );
> >   Per_CPU_Control *cpu_self = _Per_CPU_Get();
> >   Thread_Control *heir;
> >
> >   _Assert( _ISR_Get_level() != 0 );
> >
> >   if ( _Thread_Is_executing_on_a_processor( scheduled_thread ) ) {
> > if ( _Scheduler_SMP_Is_processor_owned_by_us( context, scheduled_cpu
> ) ) {
> >   heir = scheduled_cpu->heir;
> >   _Thread_Dispatch_update_heir(
> > cpu_self,
> > scheduled_cpu,
> > scheduled_thread
> >   );
> > } else {
> >   /* We have to force a migration to our processor set */
> >   heir = scheduled_thread;
> > }
> >   } else {
> > heir = scheduled_thread;
> >   }
> >
> >   if ( heir != victim_thread ) {
> > _Thread_Set_CPU( heir, victim_cpu );
> > _Thread_Dispatch_update_heir( cpu_self, victim_cpu, heir );
> >   }
> > }
> >
> >
> >
> 
> > Can someone please help me understand what this function is trying to do
> and how exactly it is achieving that?  I am finding it hard to understand
> the meaning and use of the terms like cpu_self (why do we need cpu_self ?
> Is it the CPU for scheduled or for victim?),
> _Thread_Is_executing_on_a_processor( scheduled_thread ): Why would we have
> the thread already executing when we need to allocate a processor to it?
> Why are we allocating a processor then?
> >
>
> Have you looked at how the function gets called/used? Or more
> importantly, when it gets called?
>
> you see cpu_self = Per_CPU_Get();
> Have you looked at that function to see what it does yet? Does it need
> better documentation/doxygen?
>
> > Thanks,
> > Richi.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] smpstrongapa01: Improve readability

[Richi Dubey]

---
 testsuites/smptests/smpstrongapa01/init.c | 60 ++-
 1 file changed, 38 insertions(+), 22 deletions(-)

diff --git a/testsuites/smptests/smpstrongapa01/init.c 
b/testsuites/smptests/smpstrongapa01/init.c
index bf8bc05231..ab6b0fe328 100644
--- a/testsuites/smptests/smpstrongapa01/init.c
+++ b/testsuites/smptests/smpstrongapa01/init.c
@@ -16,7 +16,7 @@
 #include "config.h"
 #endif
 
-#include "tmacros.h"
+#include 
 
 #include 
 
@@ -30,9 +30,22 @@ const char rtems_test_name[] = "SMPSTRONGAPA 1";
 
 #define ALL ((UINT32_C(1) << CPU_COUNT) - 1)
 
-#define IDLE UINT8_C(255)
+typedef enum {
+  T0,
+  T1,
+  T2,
+  T3,
+  T4,
+  T5,
+  T6,
+  T7
+  T8,
+  T9,
+  T10,
+  T11,
+  IDLE
+} task_index;
 
-#define NAME rtems_build_name('S', 'A', 'P', 'A')
 
 typedef struct {
   enum {
@@ -43,7 +56,7 @@ typedef struct {
 KIND_UNBLOCK
   } kind;
 
-  size_t index;
+  task_index index;
 
   struct {
 rtems_task_priority priority;
@@ -102,17 +115,17 @@ typedef struct {
 
 static const test_action test_actions[] = {
   RESET,
-  UNBLOCK(  0,   0, IDLE, IDLE, IDLE),
-  UNBLOCK(  1,   0,1, IDLE, IDLE),
-  UNBLOCK(  2,   0,1,2, IDLE),
-  UNBLOCK(  3,   0,1,2,3),
-  UNBLOCK(  5,   0,1,2,3),
-  SET_PRIORITY( 3,  P(4),0,1,2,3),
-  SET_PRIORITY( 5,  P(3),0,1,2,5),
-  BLOCK(5,   0,1,2,3),
-  SET_AFFINITY( 5,   ALL,0,1,2,3),
+  UNBLOCK(  T0,   T0, IDLE, IDLE, IDLE),
+  UNBLOCK(  T1,   T0,T1, IDLE, IDLE),
+  UNBLOCK(  T2,   T0,T1,T2, IDLE),
+  UNBLOCK(  T3,   T0,T1,T2,T3),
+  UNBLOCK(  T5,   T0,T1,T2,T3),
+  SET_PRIORITY( T3,  P(4),T0,T1,T2,T3),
+  SET_PRIORITY( T5,  P(3),T0,T1,T2,T5),
+  BLOCK(T5,   T0,T1,T2,T3),
+  SET_AFFINITY( T5,   ALL,T0,T1,T2,T3),
   RESET,
-  UNBLOCK(  0,   0, IDLE, IDLE, IDLE),
+  UNBLOCK(  T0,   T0, IDLE, IDLE, IDLE),
   RESET
 };
 
@@ -130,7 +143,7 @@ static void set_affinity(rtems_id id, uint32_t cpu_set_32)
 {
   rtems_status_code sc;
   cpu_set_t cpu_set;
-  size_t i;
+  task_index i;
 
   CPU_ZERO(&cpu_set);
 
@@ -147,7 +160,7 @@ static void set_affinity(rtems_id id, uint32_t cpu_set_32)
 static void reset(test_context *ctx)
 {
   rtems_status_code sc;
-  size_t i;
+  task_index i;
 
   for (i = CPU_COUNT; i < TASK_COUNT; ++i) {
 set_priority(ctx->task_ids[i], P(i));
@@ -179,10 +192,10 @@ static void reset(test_context *ctx)
 
 static void check_cpu_allocations(test_context *ctx, const test_action *action)
 {
-  size_t i;
+  task_index i;
 
   for (i = 0; i < CPU_COUNT; ++i) {
-size_t e;
+task_index e;
 const Per_CPU_Control *c;
 const Thread_Control *h;
 
@@ -206,7 +219,7 @@ static void timer(rtems_id id, void *arg)
 {
   test_context *ctx;
   rtems_status_code sc;
-  size_t i;
+  task_index i;
 
   ctx = arg;
   i = ctx->action_index;
@@ -271,7 +284,7 @@ static void test(void)
 {
   test_context *ctx;
   rtems_status_code sc;
-  size_t i;
+  task_index i;
 
   ctx = &test_instance;
 
@@ -279,7 +292,7 @@ static void test(void)
 
   for (i = 0; i < TASK_COUNT; ++i) {
 sc = rtems_task_create(
-  NAME,
+  rtems_build_name(' ', ' ', 'T', '0' + i),
   P(i),
   RTEMS_MINIMUM_STACK_SIZE,
   RTEMS_DEFAULT_MODES,
@@ -292,7 +305,10 @@ static void test(void)
 rtems_test_assert(sc == RTEMS_SUCCESSFUL);
   }
 
-  sc = rtems_timer_create(NAME, &ctx->timer_id);
+  sc = rtems_timer_create(
+  rtems_build_name('S', 'A', 'P', 'A'),
+   &ctx->timer_id
+   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
   sc = rtems_timer_fire_after(ctx->timer_id, 1, timer, ctx);
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [5.0.0-m2006-2] Test compilation error in riscv bsps

[Chris Johns]

On 22/6/20 2:11 am, jan.som...@dlr.de wrote:

Hello,

I just tried to compile some riscv bsps with tests enabled and got a compile 
time error for the dl06 test.
I tried with griscv and rv32imac with the following configure:

../rtems-5.0.0-m2006-2/configure --target=riscv-rtems5 --prefix../install/bsps 
--disable-networking --enable-tests --enable-rtemsbsp=griscv

I got the following error:

rtems-ld -r /localdata2/somm_ja/rtems/5-0-rc/build-riscv/riscv-rtems5/c/griscv \
   -C riscv-rtems5-gcc -c "-march=rv32imafd -mabi=ilp32d" \
   -O rap -b dl06.pre -e rtems_main -s \
   -o dl06.rap dl06-o1.o dl06-o2.o -lm
error: rap::object: Section index '0' not found: dl06-o1.o


Thank you for reporting this. I can reproduce it.

Please raise a ticket and assign it to the 5.2 milestone.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel