[EMAIL PROTECTED] wrote: > Quoting Jan Kiszka <[EMAIL PROTECTED]>: >> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
