On 02/11/2014 02:22 PM, Marcel van Mierlo wrote:
> I have noticed that MSW increases (at 1Hz) on MAIN in the test app which
> is just for(;;) {tm_wkafter(1000);} which surprises, expecially given
> TXTX is very similar code but has no increasing MSW.
Hi,
The "MAIN" thread is automatically shado
On 11/02/14 11:59, Gilles Chanteperdrix wrote:
On 02/11/2014 12:39 PM, Marcel van Mierlo wrote:
On 10/02/14 18:45, Gilles Chanteperdrix wrote:
On 02/10/2014 01:10 PM, Marcel van Mierlo wrote:
Here is a simple manual test application which allows me to
recreate the
problem - including trivia
On 02/11/2014 12:39 PM, Marcel van Mierlo wrote:
On 10/02/14 18:45, Gilles Chanteperdrix wrote:
On 02/10/2014 01:10 PM, Marcel van Mierlo wrote:
Here is a simple manual test application which allows me to recreate the
problem - including trivial makefile. Target platform is BeagleBone
Black -
On 10/02/14 18:45, Gilles Chanteperdrix wrote:
On 02/10/2014 01:10 PM, Marcel van Mierlo wrote:
Here is a simple manual test application which allows me to recreate the
problem - including trivial makefile. Target platform is BeagleBone
Black - (ARMV7-A).
I will dig deeper into alignment conf
On 02/10/2014 01:10 PM, Marcel van Mierlo wrote:
>
> Here is a simple manual test application which allows me to recreate the
> problem - including trivial makefile. Target platform is BeagleBone
> Black - (ARMV7-A).
>
>
> I will dig deeper into alignment configuration and compiler version. I
On 02/10/2014 01:10 PM, Marcel van Mierlo wrote:
>
> Here is a simple manual test application which allows me to recreate the
> problem - including trivial makefile. Target platform is BeagleBone
> Black - (ARMV7-A).
>
>
> I will dig deeper into alignment configuration and compiler version. I
Here is a simple manual test application which allows me to recreate the
problem - including trivial makefile. Target platform is BeagleBone
Black - (ARMV7-A).
I will dig deeper into alignment configuration and compiler version. I
notice that MSW and TRAP 8 is increasing for the TXTX and MA
On 07/02/14 19:23, Gilles Chanteperdrix wrote:
On 02/07/2014 04:22 PM, Marcel van Mierlo wrote:
On 07/02/14 15:10, Gilles Chanteperdrix wrote:
On 02/07/2014 04:07 PM, Marcel van Mierlo wrote:
TASK cio_watchdog_kick(void)
{
u_long cantmsg[4];
This one should be properly aligned, what
On 02/07/2014 04:22 PM, Marcel van Mierlo wrote:
On 07/02/14 15:10, Gilles Chanteperdrix wrote:
On 02/07/2014 04:07 PM, Marcel van Mierlo wrote:
TASK cio_watchdog_kick(void)
{
u_long cantmsg[4];
This one should be properly aligned, what about the buffer you use for
q_recv?
Hmmm, ag
On 07/02/14 15:10, Gilles Chanteperdrix wrote:
On 02/07/2014 04:07 PM, Marcel van Mierlo wrote:
TASK cio_watchdog_kick(void)
{
u_long cantmsg[4];
This one should be properly aligned, what about the buffer you use for
q_recv?
Hmmm, again, created on the stack. Here is the code for ta
On 07/02/14 14:38, Gilles Chanteperdrix wrote:
On 02/07/2014 03:32 PM, Marcel van Mierlo wrote:
If I comment out q_send TRAP 8 dosent occur. If I pass NULL as data
words to q_send, TRAP 8 stops... and %CPU remains lowhmmm do I need
to ensure stack alignment somehow?
The stack alignment is
On 02/07/2014 04:07 PM, Marcel van Mierlo wrote:
TASK cio_watchdog_kick(void)
{
u_long cantmsg[4];
This one should be properly aligned, what about the buffer you use for
q_recv?
--
Gilles.
___
Xen
On 02/07/2014 03:32 PM, Marcel van Mierlo wrote:
If I comment out q_send TRAP 8 dosent occur. If I pass NULL as data
words to q_send, TRAP 8 stops... and %CPU remains lowhmmm do I need
to ensure stack alignment somehow?
The stack alignment is ensured by the compiler. Starting with ARM EABI,
On 07/02/14 14:06, Philippe Gerum wrote:
On 02/07/2014 02:32 PM, Marcel van Mierlo wrote:
- When I comment out q_send (so only call tm_wakeafter) MSW does
not increase and stays on zero.
*** Why does q_send cause mode switches?
Where do the data words passed to qsend() come from? P
On 02/07/2014 02:32 PM, Marcel van Mierlo wrote:
- I cant see how to set T_WARNSW using the pSOS skin.
- I get warning that "T_FPU" redefined when including native/task.h
and psos+/psos.h
- If I hack the mask by using "0x0004" explicitly I get
SIGXCPU: CPU time limit exceeded when c
On 02/07/2014 02:32 PM, Marcel van Mierlo wrote:
- When I comment out q_send (so only call tm_wakeafter) MSW does
not increase and stays on zero.
*** Why does q_send cause mode switches?
Where do the data words passed to qsend() come from? Plain regular memory?
Also, what does /proc
On 02/07/2014 02:32 PM, Marcel van Mierlo wrote:
- Why is printf/fflush impacting time taken to invoke q_send?
Depending on how you measure this, but since printf/fflush will turn
your thread to secondary mode, qsend() won't be charged for the same
transition it (unexpectedly) requires sinc
On 02/07/2014 02:32 PM, Marcel van Mierlo wrote:
- I cant see how to set T_WARNSW using the pSOS skin.
- I get warning that "T_FPU" redefined when including native/task.h
and psos+/psos.h
- If I hack the mask by using "0x0004" explicitly I get
SIGXCPU: CPU time limit exceeded when c
On 07/02/14 08:53, Philippe Gerum wrote:
On 02/06/2014 08:00 PM, Gilles Chanteperdrix wrote:
On 02/06/2014 06:26 PM, Philippe Gerum wrote:
Every 2.0s: cat /proc/xenomai/stat Sat Jan 1
00:09:03 2000
CPU PIDMSWCSWPFSTAT %CPU NAME
0 0
On 02/06/2014 08:00 PM, Gilles Chanteperdrix wrote:
On 02/06/2014 06:26 PM, Philippe Gerum wrote:
Every 2.0s: cat /proc/xenomai/stat Sat Jan 1
00:09:03 2000
CPU PIDMSWCSWPFSTAT %CPU NAME
0 0 0 186436 0 00500080 9
On 02/06/2014 06:26 PM, Philippe Gerum wrote:
Every 2.0s: cat /proc/xenomai/stat Sat Jan 1
00:09:03 2000
CPU PIDMSWCSWPFSTAT %CPU NAME
0 0 0 186436 0 00500080 94.2 ROOT/0
0 2882 16 4270
On 02/06/2014 05:25 PM, Marcel van Mierlo wrote:
Hi,
I've been investigating this for a couple of days and would really
appreciate some insight
on what might be going on or what I can do to progress this...
I am porting a legacy pSOS application - to Xenomai on BeagleBoard Black
3.8 kernel
and
On 02/06/2014 06:26 PM, Philippe Gerum wrote:
On 02/06/2014 05:25 PM, Marcel van Mierlo wrote:
Hi,
I've been investigating this for a couple of days and would really
appreciate some insight
on what might be going on or what I can do to progress this...
I am porting a legacy pSOS application -
Hi Gilles, I appreciate the input:
By observation, it is 100ms (using a trace function it looks nice and
stable):
common_io.c cio_watchdog_kick +280 036.726273s: "WAKING"
common_io.c cio_watchdog_kick +280 036.826273s: "WAKING"
common_io.c cio_watchdog_kick +280 036.926272s: "WAKING"
common_io
On 02/06/2014 05:25 PM, Marcel van Mierlo wrote:
Hi,
I've been investigating this for a couple of days and would really
appreciate some insight
on what might be going on or what I can do to progress this...
I am porting a legacy pSOS application - to Xenomai on BeagleBoard Black
3.8 kernel
and
Hi,
I've been investigating this for a couple of days and would really
appreciate some insight
on what might be going on or what I can do to progress this...
I am porting a legacy pSOS application - to Xenomai on BeagleBoard Black
3.8 kernel
and have noticed %CPU (via. top) of MAIN around 40%
26 matches
Mail list logo
