[Xenomai-core] Found bug in pSOS ev_receive()

2007-02-07 Thread Markus Osterried 
Hello,

in pSOS skin function ev_receive() in file event.c I've found a bug.
When  ev_receive() is called with EV_WAIT and an event is received, the
task is unblocked and everything is okay, then in this case the copy of the
actual received events into *events_r is missing.

Regards
Markus




___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Found bug in pSOS ev_receive()

2007-02-07 Thread Philippe Gerum 
On Wed, 2007-02-07 at 11:36 +0100, Markus Osterried wrote:
 Hello,
 
 in pSOS skin function ev_receive() in file event.c I've found a bug.
 When  ev_receive() is called with EV_WAIT and an event is received, the
 task is unblocked and everything is okay, then in this case the copy of the
 actual received events into *events_r is missing.

Confirmed and fixed, thanks.

--- ksrc/skins/psos+/event.c(revision 2108)
+++ ksrc/skins/psos+/event.c(working copy)
@@ -79,9 +79,10 @@
 
if (xnthread_test_info(task-threadbase, XNBREAK))
err = -EINTR;
-   else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
+   else {
*events_r = task-waitargs.evgroup.events;
-   err = ERR_TIMEOUT;
+   if (xnthread_test_info(task-threadbase, XNTIMEO))
+   err = ERR_TIMEOUT;
}
 
   unlock_and_exit:

-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Found bug in pSOS ev_receive()

2007-02-07 Thread Philippe Gerum 
On Wed, 2007-02-07 at 11:57 +0100, Philippe Gerum wrote:
 On Wed, 2007-02-07 at 11:36 +0100, Markus Osterried wrote:
  Hello,
  
  in pSOS skin function ev_receive() in file event.c I've found a bug.
  When  ev_receive() is called with EV_WAIT and an event is received, the
  task is unblocked and everything is okay, then in this case the copy of the
  actual received events into *events_r is missing.
 
 Confirmed and fixed, thanks.
 
 --- ksrc/skins/psos+/event.c  (revision 2108)
 +++ ksrc/skins/psos+/event.c  (working copy)
 @@ -79,9 +79,10 @@
  
   if (xnthread_test_info(task-threadbase, XNBREAK))
   err = -EINTR;
 - else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
 + else {
   *events_r = task-waitargs.evgroup.events;
 - err = ERR_TIMEOUT;
 + if (xnthread_test_info(task-threadbase, XNTIMEO))
 + err = ERR_TIMEOUT;
   }
  
unlock_and_exit:
 

Actually, there was a second bug hiding in the timeout case, where the
copy back value was wrong, we should have returned the current state of
the event flag group and we returned the pended event mask instead. The
following patch against 2.3.0 fixes both issues.

--- ksrc/skins/psos+/event.c(revision 2134)
+++ ksrc/skins/psos+/event.c(working copy)
@@ -80,9 +80,10 @@
if (xnthread_test_info(task-threadbase, XNBREAK))
err = -EINTR;
else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
+   err = ERR_TIMEOUT;
+   *events_r = evgroup-events;
+   } else
*events_r = task-waitargs.evgroup.events;
-   err = ERR_TIMEOUT;
-   }
 
   unlock_and_exit:
 

-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Antwort: Re: [Xenomai-core] Found bug in pSOS ev_receive()

2007-02-07 Thread Markus Osterried 

In timeout case events_r is don't care.
When using pSOS skin in user space, __ev_receive() in syscall.c copy
events_r to user space only when ev_receive was successful.
But this comply with pSOS manual: If successful, ev_receive() returns the
actual events captured by the call in the
location pointed to by events_r.






   
  Philippe Gerum
   
  [EMAIL PROTECTED] An:  Markus 
Osterried [EMAIL PROTECTED] 
  g  Kopie:   
xenomai-core@gna.org
  Gesendet von:   Blindkopie:   
   
  Philippe Gerum  Thema:   Re: 
[Xenomai-core] Found bug in pSOS ev_receive()   
  philippe.gerum   
   
  @gmail.com   
   

   

   
  07.02.2007
   
  12:15 
   
  Bitte antworten   
   
  an rpm
   

   

   




On Wed, 2007-02-07 at 11:57 +0100, Philippe Gerum wrote:
 On Wed, 2007-02-07 at 11:36 +0100, Markus Osterried wrote:
  Hello,
 
  in pSOS skin function ev_receive() in file event.c I've found a bug.
  When  ev_receive() is called with EV_WAIT and an event is received, the
  task is unblocked and everything is okay, then in this case the copy of
the
  actual received events into *events_r is missing.

 Confirmed and fixed, thanks.

 --- ksrc/skins/psos+/event.c (revision 2108)
 +++ ksrc/skins/psos+/event.c (working copy)
 @@ -79,9 +79,10 @@

if (xnthread_test_info(task-threadbase, XNBREAK))
err = -EINTR;
 -  else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
 +  else {
*events_r = task-waitargs.evgroup.events;
 -  err = ERR_TIMEOUT;
 +  if (xnthread_test_info(task-threadbase,
XNTIMEO))
 +  err = ERR_TIMEOUT;
}

unlock_and_exit:


Actually, there was a second bug hiding in the timeout case, where the
copy back value was wrong, we should have returned the current state of
the event flag group and we returned the pended event mask instead. The
following patch against 2.3.0 fixes both issues.

--- ksrc/skins/psos+/event.c (revision 2134)
+++ ksrc/skins/psos+/event.c (working copy)
@@ -80,9 +80,10 @@
 if (xnthread_test_info(task-threadbase, XNBREAK))
 err = -EINTR;
 else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
+err = ERR_TIMEOUT;
+*events_r = evgroup-events;
+} else
 *events_r = task-waitargs.evgroup.events;
-err = ERR_TIMEOUT;
-}

   unlock_and_exit:


--
Philippe.









___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: Antwort: Re: [Xenomai-core] Found bug in pSOS ev_receive()

2007-02-07 Thread Philippe Gerum 
On Wed, 2007-02-07 at 12:51 +0100, Markus Osterried wrote:
 In timeout case events_r is don't care.

I would swear having seen a copy back being documented in the timeout
case in some oldish pSOS 2.3 manual a looong time ago, but since I don't
have it at hand anymore, maybe it's just -ENOBRAIN on my side.

 When using pSOS skin in user space, __ev_receive() in syscall.c copy
 events_r to user space only when ev_receive was successful.
 But this comply with pSOS manual: If successful, ev_receive() returns the
 actual events captured by the call in the
 location pointed to by events_r.

Good. Thanks.

 
 
 
 
   
  
   Philippe Gerum  
  
   [EMAIL PROTECTED] An:  Markus 
 Osterried [EMAIL PROTECTED] 
   g  Kopie:   
 xenomai-core@gna.org  
   
   Gesendet von:   Blindkopie: 
  
   Philippe Gerum  Thema:   Re: 
 [Xenomai-core] Found bug in pSOS ev_receive()   
   philippe.gerum 
  
   @gmail.com 
  
   
  
   
  
   07.02.2007  
  
   12:15   
  
   Bitte antworten 
  
   an rpm  
  
   
  
   
  
 
 
 
 
 On Wed, 2007-02-07 at 11:57 +0100, Philippe Gerum wrote:
  On Wed, 2007-02-07 at 11:36 +0100, Markus Osterried wrote:
   Hello,
  
   in pSOS skin function ev_receive() in file event.c I've found a bug.
   When  ev_receive() is called with EV_WAIT and an event is received, the
   task is unblocked and everything is okay, then in this case the copy of
 the
   actual received events into *events_r is missing.
 
  Confirmed and fixed, thanks.
 
  --- ksrc/skins/psos+/event.c (revision 2108)
  +++ ksrc/skins/psos+/event.c (working copy)
  @@ -79,9 +79,10 @@
 
 if (xnthread_test_info(task-threadbase, XNBREAK))
 err = -EINTR;
  -  else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
  +  else {
 *events_r = task-waitargs.evgroup.events;
  -  err = ERR_TIMEOUT;
  +  if (xnthread_test_info(task-threadbase,
 XNTIMEO))
  +  err = ERR_TIMEOUT;
 }
 
 unlock_and_exit:
 
 
 Actually, there was a second bug hiding in the timeout case, where the
 copy back value was wrong, we should have returned the current state of
 the event flag group and we returned the pended event mask instead. The
 following patch against 2.3.0 fixes both issues.
 
 --- ksrc/skins/psos+/event.c (revision 2134)
 +++ ksrc/skins/psos+/event.c (working copy)
 @@ -80,9 +80,10 @@
  if (xnthread_test_info(task-threadbase, XNBREAK))
  err = -EINTR;
  else if (xnthread_test_info(task-threadbase, XNTIMEO)) {
 +err = ERR_TIMEOUT;
 +*events_r = evgroup-events;
 +} else
  *events_r = task-waitargs.evgroup.events;
 -err = ERR_TIMEOUT;
 -}
 
unlock_and_exit:
 
 
 --
 Philippe.
 
 
 
 
 
 
 
 
-- 
Philippe.



___
Xenomai-core

[Xenomai-core] system() question

2007-02-07 Thread Stéphane ANCELOT 
Is there a way to launch my realtime task from another linux program 
using system() C call ?


I have tried it , but when system call dies my rt task dies too ...
any idea ?
steph


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Buildbot: uses 2.6.19 kernel. Sim has a problem

2007-02-07 Thread Philippe Gerum 
On Tue, 2007-02-06 at 07:47 +0100, Niklaus Giger wrote:
 Hi
 
 After spending a week skiing I discovered that I had to update the buildbot 
 to 
 use the 2.6.19 kernels everywhere. Seems to work.
 
 I also found that since February 2 I get the following error message
  
 g++ -DHAVE_CONFIG_H -I. -I. -I../include -fno-exceptions -D__XENO_SIM__ 
 -I./.. -O2 -MT 
 libmvm_la-thread.lo -MD -MP -MF .deps/libmvm_la-thread.Tpo -c 
 thread.cc  -fPIC -DPIC -o .libs/libmvm_la-thread.o
 thread.cc:66: error: 'int MvmThread::globalTrace' is not a static member 
 of 'class MvmThread'
 make[1]: *** [libmvm_la-thread.lo] Fehler 1
 For details look at 
 http://ngiger.dyndns.org/buildbot-full/sim_f/builds/86/step-make_sim/1
 

Fixed, thanks.

 Best regards
 
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] system() question

2007-02-07 Thread Gilles Chanteperdrix 
Stéphane ANCELOT wrote:
 Is there a way to launch my realtime task from another linux program 
 using system() C call ?
 
 I have tried it , but when system call dies my rt task dies too ...
 any idea ?

Why does the system call die ? Do you observe the same behaviour with
non xenomai applications ?

-- 
 Gilles Chanteperdrix

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Linux lock-up with rtcanrecv

2007-02-07 Thread Jan Kiszka 
Hi all,

fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
is still a bug in trunk /wrt broken timeouts of rt_dev_read on
xeno_16550A - different issue...), I ran into a weird behaviour of
rtcanrecv:

I have a continuous stream of a few thousand packets/s towards the
robot. When I start up two rtcanrecv rtcan0 -p1000 instances (or one +
our own receiver application), the second one causes a Linux lock-up.
Sometimes this happens during startup of the second rtcanrecv, but at
latest on its termination. Other RT tasks are still running. I can
resolve the lock-up by pulling the CAN cable, everyone is fine
afterwards and can be cleaned up. I played with quite a few combinations
of recent ipipe patches and Xenomai revisions (even back to #1084 in
v2.3.x), no noticeable difference.

Seems like I have to take a closer look - once time permits and the
robot is available. So any ideas or attempts to reproduce this are
welcome, current .config attached (no magic knob found there yet).

Jan


PS: Wolfgang, any objections against decoupling -v from -p and
lowering the receiver priority to 0?

Index: src/utils/can/rtcanrecv.c
===
--- src/utils/can/rtcanrecv.c   (revision 2146)
+++ src/utils/can/rtcanrecv.c   (working copy)
@@ -192,6 +192,7 @@ int main(int argc, char **argv)

case 'p':
print = strtoul(optarg, NULL, 0);
+   break;

case 'v':
verbose = 1;
@@ -312,7 +313,7 @@ int main(int argc, char **argv)
 }

 snprintf(name, sizeof(name), rtcanrecv-%d, getpid());
-ret = rt_task_shadow(rt_task_desc, name, 1, 0);
+ret = rt_task_shadow(rt_task_desc, name, 0, 0);
 if (ret) {
fprintf(stderr, rt_task_shadow: %s\n, strerror(-ret));
goto failure;



config.bz2
Description: Binary data


signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Linux lock-up with rtcanrecv

2007-02-07 Thread Jan Kiszka 
Jan Kiszka wrote:
 Hi all,
 
 fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
 is still a bug in trunk /wrt broken timeouts of rt_dev_read on
 xeno_16550A - different issue...), I ran into a weird behaviour of
 rtcanrecv:
 
 I have a continuous stream of a few thousand packets/s towards the
 robot. When I start up two rtcanrecv rtcan0 -p1000 instances (or one +
 our own receiver application), the second one causes a Linux lock-up.
 Sometimes this happens during startup of the second rtcanrecv, but at
 latest on its termination. Other RT tasks are still running. I can
 resolve the lock-up by pulling the CAN cable, everyone is fine
 afterwards and can be cleaned up. I played with quite a few combinations
 of recent ipipe patches and Xenomai revisions (even back to #1084 in
 v2.3.x), no noticeable difference.
 

Forgot to mention one further observation: removing the usleep form
rtcanrecv's cleanup() works around the shutdown lock-up. I can't
interpret this yet. [BTW, Wolfgang, what is it good for?]

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] system() question

2007-02-07 Thread Stéphane ANCELOT 
my linux user task uses a system() call in order to call a bash script 
to restart the realtime task as follow :


user interface C call :
system(restart_task.sh);
give back hand to user interface





bash script restart_task.sh :
killall -15 mytask
sleep 2
mytask 


system call dies because sh script has been launched

Gilles Chanteperdrix wrote:

Stéphane ANCELOT wrote:
Is there a way to launch my realtime task from another linux program 
using system() C call ?


I have tried it , but when system call dies my rt task dies too ...
any idea ?


Why does the system call die ? Do you observe the same behaviour with
non xenomai applications ?




___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core