Re: [Xenomai-core] Port to stmp3xxx (arm based)

2011-09-18 Thread Gilles Chanteperdrix 
On 09/17/2011 05:15 PM, Bertold Van den Bergh wrote:
 Hello,
 
 I am trying to port Xenomai to the freescale stmp3xxx cpu (I.MX233).
 
 I added TSC code from plat-s3c24xx as this processor also uses a 16
 bit downcounter based timer. I run the system tick counter and the TSC
 freerunning counter at 32KHz (I plan to speed it up to increase
 precision but I have a question about that). I have monitored the TSC
 output and it is a monotonic count without jumps forward or backward.
 Xenomai and linux boots fine. I can also start xenomai tasks, and they
 even appear to work to some extent.

The mask member filled by __ipipe_mach_get_tscinfo is wrong, the right
mask for a 16 bits counter is 0x

-- 
Gilles.

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

Re: [Xenomai-core] Policy switching and XNOTHER maintenance

2011-09-18 Thread Jan Kiszka 
On 2011-09-18 16:02, Philippe Gerum wrote:
 On Fri, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
 On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
 On 09/11/2011 04:29 PM, Jan Kiszka wrote:
 On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
 On 09/11/2011 12:50 PM, Jan Kiszka wrote:
 Hi all,

 just looked into the hrescnt issue again, specifically the corner case
 of a shadow thread switching from real-time policy to SCHED_OTHER.

 Doing this while holding a mutex looks invalid.

 Looking at POSIX e.g., is there anything in the spec that makes this
 invalid? If the kernel preserves or established proper priority
 boosting, I do not see what could break in principle.

 It is nothing I would design into some app, but we should somehow handle
 it (doc update or code adjustments).

 If we do not do it, the current code is valid.

 Except for its dependency on XNOTHER which is not updated on RT-NORMAL
 transitions.

 The fact that this update did not take place made the code work. No 
 negative rescnt could happen with that code.

 Anyway, here is a patch to allow switching back from RT to NORMAL, but 
 send a SIGDEBUG to a thread attempting to release a mutex while its 
 counter is already 0. We end up avoiding a big chunk of code that would 
 have been useful for a really strange corner case.


 Here comes version 2:
 diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
 index 6399a17..417170f 100644
 --- a/include/nucleus/sched-idle.h
 +++ b/include/nucleus/sched-idle.h
 @@ -39,6 +39,8 @@ extern struct xnsched_class xnsched_class_idle;
  static inline void __xnsched_idle_setparam(struct xnthread *thread,
 const union xnsched_policy_param *p)
  {
 +if (xnthread_test_state(thread, XNSHADOW))
 +xnthread_clear_state(thread, XNOTHER);
  thread-cprio = p-idle.prio;
  }
  
 diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
 index 71f655c..cc1cefa 100644
 --- a/include/nucleus/sched-rt.h
 +++ b/include/nucleus/sched-rt.h
 @@ -86,6 +86,12 @@ static inline void __xnsched_rt_setparam(struct xnthread 
 *thread,
   const union xnsched_policy_param *p)
  {
  thread-cprio = p-rt.prio;
 +if (xnthread_test_state(thread, XNSHADOW)) {
 +if (thread-cprio)
 +xnthread_clear_state(thread, XNOTHER);
 +else
 +xnthread_set_state(thread, XNOTHER);
 +}
  }
  
  static inline void __xnsched_rt_getparam(struct xnthread *thread,
 diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
 index 9a02e80..d1f 100644
 --- a/ksrc/nucleus/pod.c
 +++ b/ksrc/nucleus/pod.c
 @@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct xnthread 
 *thread,
  xnsched_putback(thread);
  
  #ifdef CONFIG_XENO_OPT_PERVASIVE
 -/*
 - * A non-real-time shadow may upgrade to real-time FIFO
 - * scheduling, but the latter may never downgrade to
 - * SCHED_NORMAL Xenomai-wise. In the valid case, we clear
 - * XNOTHER to reflect the change. Note that we keep handling
 - * non real-time shadow specifics in higher code layers, not
 - * to pollute the core scheduler with peculiarities.
 - */
 -if (sched_class == xnsched_class_rt  sched_param-rt.prio  0)
 -xnthread_clear_state(thread, XNOTHER);
  if (propagate) {
  if (xnthread_test_state(thread, XNRELAX))
  xnshadow_renice(thread);
 diff --git a/ksrc/nucleus/sched-sporadic.c b/ksrc/nucleus/sched-sporadic.c
 index fd37c21..ffc9bab 100644
 --- a/ksrc/nucleus/sched-sporadic.c
 +++ b/ksrc/nucleus/sched-sporadic.c
 @@ -258,6 +258,8 @@ static void xnsched_sporadic_setparam(struct xnthread 
 *thread,
  }
  }
  
 +if (xnthread_test_state(thread, XNSHADOW))
 +xnthread_clear_state(thread, XNOTHER);
  thread-cprio = p-pss.current_prio;
  }
  
 diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
 index 43a548e..a2af1d3 100644
 --- a/ksrc/nucleus/sched-tp.c
 +++ b/ksrc/nucleus/sched-tp.c
 @@ -100,6 +100,8 @@ static void xnsched_tp_setparam(struct xnthread *thread,
  {
  struct xnsched *sched = thread-sched;
  
 +if (xnthread_test_state(thread, XNSHADOW))
 +xnthread_clear_state(thread, XNOTHER);
  thread-tps = sched-tp.partitions[p-tp.ptid];
  thread-cprio = p-tp.prio;
  }
 diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
 index b956e46..47bc0c5 100644
 --- a/ksrc/nucleus/synch.c
 +++ b/ksrc/nucleus/synch.c
 @@ -684,9 +684,13 @@ xnsynch_release_thread(struct xnsynch *synch, struct 
 xnthread *lastowner)
  
  XENO_BUGON(NUCLEUS, !testbits(synch-status, XNSYNCH_OWNER));
  
 -if (xnthread_test_state(lastowner, XNOTHER))
 -xnthread_dec_rescnt(lastowner);
 -XENO_BUGON(NUCLEUS, xnthread_get_rescnt(lastowner)  0);
 +if (xnthread_test_state(lastowner, XNOTHER)) {
 +if (xnthread_get_rescnt(lastowner)

Re: [Xenomai-core] Port to stmp3xxx (arm based)

2011-09-18 Thread Bertold Van den Bergh 
Hello,

Thanks for the reply. The timer register has the following layout: bit
0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking
at the code this cannot work so I added an extra field to indicate the
shift after applying the mask.

Now the userspace latency test prorgam gives valid latencies, sadly
it's still -1ms to 3ms latency.

How should I proceed troubleshooting this?
Looking at the ipipe trace it looks the task is brought op quite fast
after the interrupt fires so I think it is set at the wrong time, I'm
going to look into this.

Sincerely,
Bertold Van den Bergh
On Sun, Sep 18, 2011 at 3:09 PM, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
 On 09/17/2011 05:15 PM, Bertold Van den Bergh wrote:
 Hello,

 I am trying to port Xenomai to the freescale stmp3xxx cpu (I.MX233).

 I added TSC code from plat-s3c24xx as this processor also uses a 16
 bit downcounter based timer. I run the system tick counter and the TSC
 freerunning counter at 32KHz (I plan to speed it up to increase
 precision but I have a question about that). I have monitored the TSC
 output and it is a monotonic count without jumps forward or backward.
 Xenomai and linux boots fine. I can also start xenomai tasks, and they
 even appear to work to some extent.

 The mask member filled by __ipipe_mach_get_tscinfo is wrong, the right
 mask for a 16 bits counter is 0x

 --
                                                                Gilles.


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

Re: [Xenomai-core] Port to stmp3xxx (arm based)

2011-09-18 Thread Gilles Chanteperdrix 
On 09/18/2011 04:43 PM, Bertold Van den Bergh wrote:
 Hello,
 
 Thanks for the reply. The timer register has the following layout: bit
 0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking
 at the code this cannot work so I added an extra field to indicate the
 shift after applying the mask.

You should really upgrade your I-pipe tree to a more recent one, where
the support for tsc emulation was factored. You would add the new case
to the tsc implementations in kernel-space, and nowhere else. When you
are done, please send a patch.

 
 Now the userspace latency test prorgam gives valid latencies, sadly
 it's still -1ms to 3ms latency.
 
 How should I proceed troubleshooting this?
 Looking at the ipipe trace it looks the task is brought op quite fast
 after the interrupt fires so I think it is set at the wrong time, I'm
 going to look into this.

The I-pipe tracer has a trace point at the point where the timer was
supposed to tick.

-- 
Gilles.

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

Re: [Xenomai-core] Policy switching and XNOTHER maintenance

2011-09-18 Thread Philippe Gerum 
On Sun, 2011-09-18 at 16:34 +0200, Jan Kiszka wrote:
 On 2011-09-18 16:02, Philippe Gerum wrote:
  On Fri, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
  On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
  On 09/11/2011 04:29 PM, Jan Kiszka wrote:
  On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
  On 09/11/2011 12:50 PM, Jan Kiszka wrote:
  Hi all,
 
  just looked into the hrescnt issue again, specifically the corner case
  of a shadow thread switching from real-time policy to SCHED_OTHER.
 
  Doing this while holding a mutex looks invalid.
 
  Looking at POSIX e.g., is there anything in the spec that makes this
  invalid? If the kernel preserves or established proper priority
  boosting, I do not see what could break in principle.
 
  It is nothing I would design into some app, but we should somehow handle
  it (doc update or code adjustments).
 
  If we do not do it, the current code is valid.
 
  Except for its dependency on XNOTHER which is not updated on RT-NORMAL
  transitions.
 
  The fact that this update did not take place made the code work. No 
  negative rescnt could happen with that code.
 
  Anyway, here is a patch to allow switching back from RT to NORMAL, but 
  send a SIGDEBUG to a thread attempting to release a mutex while its 
  counter is already 0. We end up avoiding a big chunk of code that would 
  have been useful for a really strange corner case.
 
 
  Here comes version 2:
  diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
  index 6399a17..417170f 100644
  --- a/include/nucleus/sched-idle.h
  +++ b/include/nucleus/sched-idle.h
  @@ -39,6 +39,8 @@ extern struct xnsched_class xnsched_class_idle;
   static inline void __xnsched_idle_setparam(struct xnthread *thread,
const union xnsched_policy_param *p)
   {
  +  if (xnthread_test_state(thread, XNSHADOW))
  +  xnthread_clear_state(thread, XNOTHER);
 thread-cprio = p-idle.prio;
   }
   
  diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
  index 71f655c..cc1cefa 100644
  --- a/include/nucleus/sched-rt.h
  +++ b/include/nucleus/sched-rt.h
  @@ -86,6 +86,12 @@ static inline void __xnsched_rt_setparam(struct 
  xnthread *thread,
  const union xnsched_policy_param *p)
   {
 thread-cprio = p-rt.prio;
  +  if (xnthread_test_state(thread, XNSHADOW)) {
  +  if (thread-cprio)
  +  xnthread_clear_state(thread, XNOTHER);
  +  else
  +  xnthread_set_state(thread, XNOTHER);
  +  }
   }
   
   static inline void __xnsched_rt_getparam(struct xnthread *thread,
  diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
  index 9a02e80..d1f 100644
  --- a/ksrc/nucleus/pod.c
  +++ b/ksrc/nucleus/pod.c
  @@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct xnthread 
  *thread,
 xnsched_putback(thread);
   
   #ifdef CONFIG_XENO_OPT_PERVASIVE
  -  /*
  -   * A non-real-time shadow may upgrade to real-time FIFO
  -   * scheduling, but the latter may never downgrade to
  -   * SCHED_NORMAL Xenomai-wise. In the valid case, we clear
  -   * XNOTHER to reflect the change. Note that we keep handling
  -   * non real-time shadow specifics in higher code layers, not
  -   * to pollute the core scheduler with peculiarities.
  -   */
  -  if (sched_class == xnsched_class_rt  sched_param-rt.prio  0)
  -  xnthread_clear_state(thread, XNOTHER);
 if (propagate) {
 if (xnthread_test_state(thread, XNRELAX))
 xnshadow_renice(thread);
  diff --git a/ksrc/nucleus/sched-sporadic.c b/ksrc/nucleus/sched-sporadic.c
  index fd37c21..ffc9bab 100644
  --- a/ksrc/nucleus/sched-sporadic.c
  +++ b/ksrc/nucleus/sched-sporadic.c
  @@ -258,6 +258,8 @@ static void xnsched_sporadic_setparam(struct xnthread 
  *thread,
 }
 }
   
  +  if (xnthread_test_state(thread, XNSHADOW))
  +  xnthread_clear_state(thread, XNOTHER);
 thread-cprio = p-pss.current_prio;
   }
   
  diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
  index 43a548e..a2af1d3 100644
  --- a/ksrc/nucleus/sched-tp.c
  +++ b/ksrc/nucleus/sched-tp.c
  @@ -100,6 +100,8 @@ static void xnsched_tp_setparam(struct xnthread 
  *thread,
   {
 struct xnsched *sched = thread-sched;
   
  +  if (xnthread_test_state(thread, XNSHADOW))
  +  xnthread_clear_state(thread, XNOTHER);
 thread-tps = sched-tp.partitions[p-tp.ptid];
 thread-cprio = p-tp.prio;
   }
  diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
  index b956e46..47bc0c5 100644
  --- a/ksrc/nucleus/synch.c
  +++ b/ksrc/nucleus/synch.c
  @@ -684,9 +684,13 @@ xnsynch_release_thread(struct xnsynch *synch, struct 
  xnthread *lastowner)
   
 XENO_BUGON(NUCLEUS, !testbits(synch-status, XNSYNCH_OWNER));
   
  -  if (xnthread_test_state(lastowner, XNOTHER))
  -  xnthread_dec_rescnt(lastowner);
  -  XENO_BUGON(NUCLEUS, xnthread_get_rescnt(lastowner)

Re: [Xenomai-core] Policy switching and XNOTHER maintenance

2011-09-18 Thread Jan Kiszka 
On 2011-09-18 17:10, Philippe Gerum wrote:
 On Sun, 2011-09-18 at 16:34 +0200, Jan Kiszka wrote:
 On 2011-09-18 16:02, Philippe Gerum wrote:
 On Fri, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
 On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
 On 09/11/2011 04:29 PM, Jan Kiszka wrote:
 On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
 On 09/11/2011 12:50 PM, Jan Kiszka wrote:
 Hi all,

 just looked into the hrescnt issue again, specifically the corner case
 of a shadow thread switching from real-time policy to SCHED_OTHER.

 Doing this while holding a mutex looks invalid.

 Looking at POSIX e.g., is there anything in the spec that makes this
 invalid? If the kernel preserves or established proper priority
 boosting, I do not see what could break in principle.

 It is nothing I would design into some app, but we should somehow handle
 it (doc update or code adjustments).

 If we do not do it, the current code is valid.

 Except for its dependency on XNOTHER which is not updated on RT-NORMAL
 transitions.

 The fact that this update did not take place made the code work. No 
 negative rescnt could happen with that code.

 Anyway, here is a patch to allow switching back from RT to NORMAL, but 
 send a SIGDEBUG to a thread attempting to release a mutex while its 
 counter is already 0. We end up avoiding a big chunk of code that would 
 have been useful for a really strange corner case.


 Here comes version 2:
 diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
 index 6399a17..417170f 100644
 --- a/include/nucleus/sched-idle.h
 +++ b/include/nucleus/sched-idle.h
 @@ -39,6 +39,8 @@ extern struct xnsched_class xnsched_class_idle;
  static inline void __xnsched_idle_setparam(struct xnthread *thread,
   const union xnsched_policy_param *p)
  {
 +  if (xnthread_test_state(thread, XNSHADOW))
 +  xnthread_clear_state(thread, XNOTHER);
thread-cprio = p-idle.prio;
  }
  
 diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
 index 71f655c..cc1cefa 100644
 --- a/include/nucleus/sched-rt.h
 +++ b/include/nucleus/sched-rt.h
 @@ -86,6 +86,12 @@ static inline void __xnsched_rt_setparam(struct 
 xnthread *thread,
 const union xnsched_policy_param *p)
  {
thread-cprio = p-rt.prio;
 +  if (xnthread_test_state(thread, XNSHADOW)) {
 +  if (thread-cprio)
 +  xnthread_clear_state(thread, XNOTHER);
 +  else
 +  xnthread_set_state(thread, XNOTHER);
 +  }
  }
  
  static inline void __xnsched_rt_getparam(struct xnthread *thread,
 diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
 index 9a02e80..d1f 100644
 --- a/ksrc/nucleus/pod.c
 +++ b/ksrc/nucleus/pod.c
 @@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct xnthread 
 *thread,
xnsched_putback(thread);
  
  #ifdef CONFIG_XENO_OPT_PERVASIVE
 -  /*
 -   * A non-real-time shadow may upgrade to real-time FIFO
 -   * scheduling, but the latter may never downgrade to
 -   * SCHED_NORMAL Xenomai-wise. In the valid case, we clear
 -   * XNOTHER to reflect the change. Note that we keep handling
 -   * non real-time shadow specifics in higher code layers, not
 -   * to pollute the core scheduler with peculiarities.
 -   */
 -  if (sched_class == xnsched_class_rt  sched_param-rt.prio  0)
 -  xnthread_clear_state(thread, XNOTHER);
if (propagate) {
if (xnthread_test_state(thread, XNRELAX))
xnshadow_renice(thread);
 diff --git a/ksrc/nucleus/sched-sporadic.c b/ksrc/nucleus/sched-sporadic.c
 index fd37c21..ffc9bab 100644
 --- a/ksrc/nucleus/sched-sporadic.c
 +++ b/ksrc/nucleus/sched-sporadic.c
 @@ -258,6 +258,8 @@ static void xnsched_sporadic_setparam(struct xnthread 
 *thread,
}
}
  
 +  if (xnthread_test_state(thread, XNSHADOW))
 +  xnthread_clear_state(thread, XNOTHER);
thread-cprio = p-pss.current_prio;
  }
  
 diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
 index 43a548e..a2af1d3 100644
 --- a/ksrc/nucleus/sched-tp.c
 +++ b/ksrc/nucleus/sched-tp.c
 @@ -100,6 +100,8 @@ static void xnsched_tp_setparam(struct xnthread 
 *thread,
  {
struct xnsched *sched = thread-sched;
  
 +  if (xnthread_test_state(thread, XNSHADOW))
 +  xnthread_clear_state(thread, XNOTHER);
thread-tps = sched-tp.partitions[p-tp.ptid];
thread-cprio = p-tp.prio;
  }
 diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
 index b956e46..47bc0c5 100644
 --- a/ksrc/nucleus/synch.c
 +++ b/ksrc/nucleus/synch.c
 @@ -684,9 +684,13 @@ xnsynch_release_thread(struct xnsynch *synch, struct 
 xnthread *lastowner)
  
XENO_BUGON(NUCLEUS, !testbits(synch-status, XNSYNCH_OWNER));
  
 -  if (xnthread_test_state(lastowner, XNOTHER))
 -  xnthread_dec_rescnt(lastowner);
 -  XENO_BUGON(NUCLEUS, xnthread_get_rescnt(lastowner)  0);
 +  if (xnthread_test_state(lastowner, XNOTHER)) {
 +  if

Re: [Xenomai-core] Policy switching and XNOTHER maintenance

2011-09-18 Thread Jan Kiszka 
On 2011-09-18 17:11, Jan Kiszka wrote:
 On 2011-09-18 17:10, Philippe Gerum wrote:
 On Sun, 2011-09-18 at 16:34 +0200, Jan Kiszka wrote:
 On 2011-09-18 16:02, Philippe Gerum wrote:
 On Fri, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
 On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
 On 09/11/2011 04:29 PM, Jan Kiszka wrote:
 On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
 On 09/11/2011 12:50 PM, Jan Kiszka wrote:
 Hi all,

 just looked into the hrescnt issue again, specifically the corner case
 of a shadow thread switching from real-time policy to SCHED_OTHER.

 Doing this while holding a mutex looks invalid.

 Looking at POSIX e.g., is there anything in the spec that makes this
 invalid? If the kernel preserves or established proper priority
 boosting, I do not see what could break in principle.

 It is nothing I would design into some app, but we should somehow handle
 it (doc update or code adjustments).

 If we do not do it, the current code is valid.

 Except for its dependency on XNOTHER which is not updated on RT-NORMAL
 transitions.

 The fact that this update did not take place made the code work. No 
 negative rescnt could happen with that code.

 Anyway, here is a patch to allow switching back from RT to NORMAL, but 
 send a SIGDEBUG to a thread attempting to release a mutex while its 
 counter is already 0. We end up avoiding a big chunk of code that would 
 have been useful for a really strange corner case.


 Here comes version 2:
 diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
 index 6399a17..417170f 100644
 --- a/include/nucleus/sched-idle.h
 +++ b/include/nucleus/sched-idle.h
 @@ -39,6 +39,8 @@ extern struct xnsched_class xnsched_class_idle;
  static inline void __xnsched_idle_setparam(struct xnthread *thread,
  const union xnsched_policy_param *p)
  {
 + if (xnthread_test_state(thread, XNSHADOW))
 + xnthread_clear_state(thread, XNOTHER);
   thread-cprio = p-idle.prio;
  }
  
 diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
 index 71f655c..cc1cefa 100644
 --- a/include/nucleus/sched-rt.h
 +++ b/include/nucleus/sched-rt.h
 @@ -86,6 +86,12 @@ static inline void __xnsched_rt_setparam(struct 
 xnthread *thread,
const union xnsched_policy_param *p)
  {
   thread-cprio = p-rt.prio;
 + if (xnthread_test_state(thread, XNSHADOW)) {
 + if (thread-cprio)
 + xnthread_clear_state(thread, XNOTHER);
 + else
 + xnthread_set_state(thread, XNOTHER);
 + }
  }
  
  static inline void __xnsched_rt_getparam(struct xnthread *thread,
 diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
 index 9a02e80..d1f 100644
 --- a/ksrc/nucleus/pod.c
 +++ b/ksrc/nucleus/pod.c
 @@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct xnthread 
 *thread,
   xnsched_putback(thread);
  
  #ifdef CONFIG_XENO_OPT_PERVASIVE
 - /*
 -  * A non-real-time shadow may upgrade to real-time FIFO
 -  * scheduling, but the latter may never downgrade to
 -  * SCHED_NORMAL Xenomai-wise. In the valid case, we clear
 -  * XNOTHER to reflect the change. Note that we keep handling
 -  * non real-time shadow specifics in higher code layers, not
 -  * to pollute the core scheduler with peculiarities.
 -  */
 - if (sched_class == xnsched_class_rt  sched_param-rt.prio  0)
 - xnthread_clear_state(thread, XNOTHER);
   if (propagate) {
   if (xnthread_test_state(thread, XNRELAX))
   xnshadow_renice(thread);
 diff --git a/ksrc/nucleus/sched-sporadic.c b/ksrc/nucleus/sched-sporadic.c
 index fd37c21..ffc9bab 100644
 --- a/ksrc/nucleus/sched-sporadic.c
 +++ b/ksrc/nucleus/sched-sporadic.c
 @@ -258,6 +258,8 @@ static void xnsched_sporadic_setparam(struct xnthread 
 *thread,
   }
   }
  
 + if (xnthread_test_state(thread, XNSHADOW))
 + xnthread_clear_state(thread, XNOTHER);
   thread-cprio = p-pss.current_prio;
  }
  
 diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
 index 43a548e..a2af1d3 100644
 --- a/ksrc/nucleus/sched-tp.c
 +++ b/ksrc/nucleus/sched-tp.c
 @@ -100,6 +100,8 @@ static void xnsched_tp_setparam(struct xnthread 
 *thread,
  {
   struct xnsched *sched = thread-sched;
  
 + if (xnthread_test_state(thread, XNSHADOW))
 + xnthread_clear_state(thread, XNOTHER);
   thread-tps = sched-tp.partitions[p-tp.ptid];
   thread-cprio = p-tp.prio;
  }
 diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
 index b956e46..47bc0c5 100644
 --- a/ksrc/nucleus/synch.c
 +++ b/ksrc/nucleus/synch.c
 @@ -684,9 +684,13 @@ xnsynch_release_thread(struct xnsynch *synch, struct 
 xnthread *lastowner)
  
   XENO_BUGON(NUCLEUS, !testbits(synch-status, XNSYNCH_OWNER));
  
 - if (xnthread_test_state(lastowner, XNOTHER))
 - xnthread_dec_rescnt(lastowner);
 - XENO_BUGON(NUCLEUS, xnthread_get_rescnt(lastowner)  0);
 + if (xnthread_test_state(lastowner, XNOTHER)) {
 + if

Re: [Xenomai-core] Policy switching and XNOTHER maintenance

2011-09-18 Thread Jan Kiszka 
On 2011-09-18 17:18, Gilles Chanteperdrix wrote:
 On 09/18/2011 05:13 PM, Jan Kiszka wrote:
 On 2011-09-18 17:11, Jan Kiszka wrote:
 On 2011-09-18 17:10, Philippe Gerum wrote:
 On Sun, 2011-09-18 at 16:34 +0200, Jan Kiszka wrote:
 On 2011-09-18 16:02, Philippe Gerum wrote:
 On Fri, 2011-09-16 at 22:39 +0200, Gilles Chanteperdrix wrote:
 On 09/16/2011 10:13 PM, Gilles Chanteperdrix wrote:
 On 09/11/2011 04:29 PM, Jan Kiszka wrote:
 On 2011-09-11 16:24, Gilles Chanteperdrix wrote:
 On 09/11/2011 12:50 PM, Jan Kiszka wrote:
 Hi all,

 just looked into the hrescnt issue again, specifically the corner 
 case
 of a shadow thread switching from real-time policy to SCHED_OTHER.

 Doing this while holding a mutex looks invalid.

 Looking at POSIX e.g., is there anything in the spec that makes this
 invalid? If the kernel preserves or established proper priority
 boosting, I do not see what could break in principle.

 It is nothing I would design into some app, but we should somehow 
 handle
 it (doc update or code adjustments).

 If we do not do it, the current code is valid.

 Except for its dependency on XNOTHER which is not updated on 
 RT-NORMAL
 transitions.

 The fact that this update did not take place made the code work. No 
 negative rescnt could happen with that code.

 Anyway, here is a patch to allow switching back from RT to NORMAL, but 
 send a SIGDEBUG to a thread attempting to release a mutex while its 
 counter is already 0. We end up avoiding a big chunk of code that 
 would 
 have been useful for a really strange corner case.


 Here comes version 2:
 diff --git a/include/nucleus/sched-idle.h b/include/nucleus/sched-idle.h
 index 6399a17..417170f 100644
 --- a/include/nucleus/sched-idle.h
 +++ b/include/nucleus/sched-idle.h
 @@ -39,6 +39,8 @@ extern struct xnsched_class xnsched_class_idle;
  static inline void __xnsched_idle_setparam(struct xnthread *thread,
const union 
 xnsched_policy_param *p)
  {
 +   if (xnthread_test_state(thread, XNSHADOW))
 +   xnthread_clear_state(thread, XNOTHER);
 thread-cprio = p-idle.prio;
  }
  
 diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
 index 71f655c..cc1cefa 100644
 --- a/include/nucleus/sched-rt.h
 +++ b/include/nucleus/sched-rt.h
 @@ -86,6 +86,12 @@ static inline void __xnsched_rt_setparam(struct 
 xnthread *thread,
  const union 
 xnsched_policy_param *p)
  {
 thread-cprio = p-rt.prio;
 +   if (xnthread_test_state(thread, XNSHADOW)) {
 +   if (thread-cprio)
 +   xnthread_clear_state(thread, XNOTHER);
 +   else
 +   xnthread_set_state(thread, XNOTHER);
 +   }
  }
  
  static inline void __xnsched_rt_getparam(struct xnthread *thread,
 diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
 index 9a02e80..d1f 100644
 --- a/ksrc/nucleus/pod.c
 +++ b/ksrc/nucleus/pod.c
 @@ -1896,16 +1896,6 @@ int __xnpod_set_thread_schedparam(struct 
 xnthread *thread,
 xnsched_putback(thread);
  
  #ifdef CONFIG_XENO_OPT_PERVASIVE
 -   /*
 -* A non-real-time shadow may upgrade to real-time FIFO
 -* scheduling, but the latter may never downgrade to
 -* SCHED_NORMAL Xenomai-wise. In the valid case, we clear
 -* XNOTHER to reflect the change. Note that we keep handling
 -* non real-time shadow specifics in higher code layers, not
 -* to pollute the core scheduler with peculiarities.
 -*/
 -   if (sched_class == xnsched_class_rt  sched_param-rt.prio  
 0)
 -   xnthread_clear_state(thread, XNOTHER);
 if (propagate) {
 if (xnthread_test_state(thread, XNRELAX))
 xnshadow_renice(thread);
 diff --git a/ksrc/nucleus/sched-sporadic.c 
 b/ksrc/nucleus/sched-sporadic.c
 index fd37c21..ffc9bab 100644
 --- a/ksrc/nucleus/sched-sporadic.c
 +++ b/ksrc/nucleus/sched-sporadic.c
 @@ -258,6 +258,8 @@ static void xnsched_sporadic_setparam(struct 
 xnthread *thread,
 }
 }
  
 +   if (xnthread_test_state(thread, XNSHADOW))
 +   xnthread_clear_state(thread, XNOTHER);
 thread-cprio = p-pss.current_prio;
  }
  
 diff --git a/ksrc/nucleus/sched-tp.c b/ksrc/nucleus/sched-tp.c
 index 43a548e..a2af1d3 100644
 --- a/ksrc/nucleus/sched-tp.c
 +++ b/ksrc/nucleus/sched-tp.c
 @@ -100,6 +100,8 @@ static void xnsched_tp_setparam(struct xnthread 
 *thread,
  {
 struct xnsched *sched = thread-sched;
  
 +   if (xnthread_test_state(thread, XNSHADOW))
 +   xnthread_clear_state(thread, XNOTHER);
 thread-tps = sched-tp.partitions[p-tp.ptid];
 thread-cprio = p-tp.prio;
  }
 diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
 index b956e46..47bc0c5 100644
 --- a/ksrc/nucleus/synch.c
 +++ b/ksrc/nucleus/synch.c
 @@ -684,9 +684,13 @@ xnsynch_release_thread(struct xnsynch *synch,

Re: [Xenomai-core] Policy switching and XNOTHER maintenance

2011-09-18 Thread Gilles Chanteperdrix 
On 09/18/2011 05:24 PM, Jan Kiszka wrote:
 On 2011-09-18 17:18, Gilles Chanteperdrix wrote:
 What about:

 diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
 index 21cc191..7fe44a1 100644
 --- a/ksrc/nucleus/shadow.c
 +++ b/ksrc/nucleus/shadow.c
 @@ -2756,9 +2756,12 @@ static inline void do_setsched_event(struct 
 task_struct *p, int priority)
  union xnsched_policy_param param;
  struct xnsched *sched;
  
 -if (!thread || p-policy != SCHED_FIFO)
 +if (!thread || (p-policy != SCHED_FIFO  p-policy != SCHED_OTHER))
  return;
  
 +if (p-policy == SCHED_OTHER)
 +priority = 0;
 +
  /*
   * Linux's priority scale is a subset of the core pod's
   * priority scale, so there is no need to bound the priority
 
 No other policies can be issued against the Linux part of a shadow? Then
 it's OK. I just don't recall the details here ATM.
 
 Jan
 

This should be OK, according to the comment:
 * BIG FAT WARNING: Change of scheduling parameters from the
 * Linux side are propagated only to threads that belong to
 * the Xenomai RT scheduling class. Threads from other classes
 * are remain unaffected, since we could not map this
 * information 1:1 between Linux and Xenomai.
 */


-- 
Gilles.

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

Re: [Xenomai-core] Port to stmp3xxx (arm based)

2011-09-18 Thread Gilles Chanteperdrix 
On 09/18/2011 04:43 PM, Bertold Van den Bergh wrote:
 Hello,
 
 Thanks for the reply. The timer register has the following layout: bit
 0-15: reload, bit 16-31: counter. Thats why I put 0x. Looking
 at the code this cannot work so I added an extra field to indicate the
 shift after applying the mask.
 
 Now the userspace latency test prorgam gives valid latencies, sadly
 it's still -1ms to 3ms latency.
 
 How should I proceed troubleshooting this?
 Looking at the ipipe trace it looks the task is brought op quite fast
 after the interrupt fires so I think it is set at the wrong time, I'm
 going to look into this.

Note that you probably have not enabled CONFIG_IPIPE_TRACE_MCOUNT, you
should enable it to get more complete traces.


-- 
Gilles.

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

Re: [Xenomai-core] Analogy DIO data acquisition with NI6259

2011-09-18 Thread Alexis Berlemont 
Hi,

On Wed, Sep 14, 2011 at 5:38 AM, Stefan Schaal ssch...@usc.edu wrote:
 This is a summary and conclusion of using a NI6259 with Xenomai/Analogy for 
 digital data I/O. First of all, many thanks to Alexis whose Analogy branch 
 really allowed us to succeed! We would just like share the final results of 
 our implementation with the hope that this might help others.

 Goals:
 We needed a 19 bit parallel I/O for bi-directional communication between a 
 host computer and a robot controller. The 32bit DIO of the NI6259 seemed to 
 well suited. The communication protocol needs about 300 DIO commands per ms, 
 where every about 20 commands the DIO port needs to switch from write to read 
 and then back.

 Problems:
 Initially we tried a4l_sync_dio() (synchronous communication). We measured 
 that one a4l_sync_dio() takes about 5us. Additionally, the switch from read 
 to write mode also seems to take some additional time. Thus, the 
 communication speed was not sufficient.

 A 2nd attempt was to use instructions and instruction lists using 
 a4l_snd_insnlist() and a4l_snd_insn(). We measure that this can bring down 
 one data acquisition to about 3.5us when all commands are queued up in an 
 instruction list, but due to the read/write switch we needed, we cannot use 
 very long instruction lists, and the read/write switch takes too long. Thus, 
 the communication speed did not improve a lot.

 A 3rd attempt was to use CMD structures. Following comedi examples, we create 
 a 200ns clock and triggered the CMD streaming with this clock. This allows 
 VERY fast DIO. But, again, the read/write switches that are needed frequently 
 made CMD structures inefficient as we could not cue up a lot of DIO commands 
 before the next read/write switch, and in order to do the read/write switch, 
 the CMD has to be aborted. We also noted that starting a CMD has some delays.

 We realized that none of these approaches was feasible.

 Solution:
 We create a simple IC-based circuit that allowed to branch the read/write DIO 
 protocol such that we could use one DIO channel of the NI6259 for write only 
 (never switched to read), and the 2nd DIO channel on the NI6259 for read only 
 (no switching). By avoiding the read/write switching, all three ideas from 
 above are possible and run fast enough (after some optimization of our 
 communication protocol). We ended up using a4l_sync_dio() as it is the 
 easiest to use, and yielded sufficient speed. With the CMD approach, we would 
 be able to go a factor 5-10 faster even.

 For you info, our interface C-code is attached. This is not general purpose 
 software, but should allow other to get the idea of what we do.

Many thanks for this feedback!



 Best wishes, and thanks again to Alexis!

 -Stefan



Alexis.

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