Re: [Xenomai-help] interrupt service routine issue

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

stefano.franzoni@domain.hid wrote:
> Dear experts
> 
> we are working on a systems with Ubuntu Linux 2.6.25.11 and Xenomai 2.4.4.
> The system has an Intel(R) Pentium(R) M processor 1.73GHz.
> The Xenomai installation seems to be ok and also native application tests
> give right results.

Are you sure about this ? To benchmark your system, you should let the
latency test run for some time (say 24 hours), with a sustained load. I
tend to like the "dohell" script to generate this load. What we could
suspect here is SMI issues.

> 
> We developed a RT application based on an ISA IRQ.
> 
> The application has two RT tasks created with rt_task_create.
> One task has maximum (99) priority waits and manages the IRQ waiting for it
> with an rt_intr_wait.
> The other task has a lower priority and manages the communication with an
> external system using TCP/IP sockets.
> 
> The IRQ arrive every 1.6 msec and the interrupt service routine takes about
> 250 usec.
> The issue is that sporadically happens that the interrupt service routine
> takes about 1.7 msec.

>From what I understand, your "interrupt service routine", is in fact a
Xenomai task which you expect to run in primary mode. Did you check
whether it is always running in primary mode? You can ask Xenomai to
send a signal to your thread if ever it switches to secondary mode,
setting a special mode bit with rt_task_set_mode/pthread_set_mode_np,
see online documentation.

Note that you should let your application run with this mode set, to see
if it is indeed what causes the overrun. There are services (malloc
comes to my mind) which will only cause a mode switch from time to time.

There are also unfortunately ways to have a primary mode thread wait for
Linux without causing a mode switch. The typical example is a mutex
shared between the two RT tasks, that the low priority task would take
before calling a plain Linux services. The high priority task locking
this mutex would in fact wait for Linux.

So, this mode bit is no silver bullet, your best option is careful code
inspection.

-- 
                                                 Gilles.