Re: [Xenomai-help] Re: [Adeos-main] [PATCH] ppc mvme5500

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4144 bytes --]

barbalace@domain.hid wrote:
> Quoting Jan Kiszka <jan.kiszka@domain.hid>:
>> Antonio, please use a recent Xenomai version (e.g. 2.2.5) to avoid that
>> we may hunt old issues.
>  Ok, could be the right solution.

Your issue is independent of the version, still 2.2.5 contains a lot of
fixes.

> 
>> Next post a simple demo code to xenomai-help,
>> showing the misbehaviour. We could then check if other archs are
>> involved, if it's reproducible on further PPC boards, or if some mistake
>> might have slipped into the code.
>> From your description I wonder if you lock the mutex in line 2 from the
>> correct context (a Xenomai thread). If you call that lock from main,
>> don't forget to invoke rt_task_shadow first.
> 
> A simplified version of the code (in the original code there is an hw DAQ and I
> understand that the same code run 2-times, here one could use a buffer to write
> for example a u(->for unlocking) and a l(->for locking) ):
> 
> /* -- START CODE HERE ---------- demo.c --------------------------------------*/
> #include <linux/config.h>
> #include <linux/version.h>
> #include <linux/module.h>
> #include <linux/moduleparam.h>
> 
> #include <native/task.h>
> #include <native/intr.h>
> #include <native/mutex.h>
> #include <native/sem.h>
> 
> 
> #define TASK_PRIO 99
> #define TASK_MODE (T_FPU | T_CPU(0))
> #define TASK_STKSZ 4096
> 
> RT_INTR intr_desc;
> RT_TASK task_desc;
> RT_MUTEX mutex_desc;
> 
> int demo_finalize;
> 
> #define INTR_IRQ 76
> 
> static irqreturn_t demo_irqhandler(void)
> {
>         rt_mutex_unlock(&mutex_desc);                        // IPC handling

You cannot unlock a mutex from a non-task context like the IRQ handler
is. Actually, the return value of that call should be EPERM, indicating
the misuse.

> 
>         return RT_INTR_HANDLED;
> }
> 
> 
> 
> void rt_handler(void *data){
> 
>         printk(KERN_ERR"entered in RT task\n");                // ok I know is
> not right use printk

There is actually no problem (except growing log files), printk is safe
from RT context under Xenomai.

>         rt_mutex_lock(&mutex_desc, TM_INFINITE);
> 
>         for(;;){
>                 rt_mutex_lock(&mutex_desc, TM_INFINITE);
> 
>                 if(demo_finalize == 1)
>                         break;
>                 /* doing something */
>         }
> 
>         return;
> }
> 
> static int demo_init(void)
> {
>         int result;
>         // initialize MUTEX
>         int err;
>         err = rt_mutex_create(&mutex_desc, "demo_mutex");
>         printk(KERN_ERR"mutex created and locked\n");
> 
>         demo_finalize = 0;
> 
>         // create the real-time task waiting for data
>         err = rt_task_create(&task_desc, "demo_acq", TASK_STKSZ, TASK_PRIO,
> TASK_MODE);
>         if (!err) {
>                 rt_task_start(&task_desc, &rt_handler, NULL);
>                 printk(KERN_ERR"RT task started!\n");
>         } else
>                 printk(KERN_ERR"can't start RT thread!!!\n");
> 
>         result = rt_intr_create(&intr_desc, "demo_intr", INTR_IRQ,
> demo_irqhandler, 0,
> 0);
> 
>         return (0);
> }
> 
> static void demo_exit(void)
> {
>         rt_intr_delete(&intr_desc);
> 
>         demo_finalize = 1;
>         rt_mutex_unlock(&mutex_desc);
> 
> 
>         rt_task_delete(&task_desc);
>         printk(KERN_ERR"demo: RT task destroyed\n");
> 
>         return;
> }
> 
> module_init(demo_init);
> module_exit(demo_exit);
> 
> /* --- END CODE HERE ---------------------------------------------------------*/
> 
> With this code and Xenomai 2.2.0 you lose the machine control... I resolve this
> using semaphores.

Using a semaphore to wake the blocked RT task up is actually the Right
Thing. Why not a mutex? A locked mutex always has an owner, which is the
task that successfully acquired it. That owner is ought to release the
mutex again - NO ONE ELSE. And having an owner allows do thing like
inheriting the priority of a waiter to the current owner - or to analyse
who forgot to release it...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]