Indeed, I have bad reproduced the problem in the code I suggest to you. But
your remark makes me understand that I was in secondary mode and I never
switched to primary mode so ....
My issue is understood and solved.
Thanks
On Thu, Feb 21, 2008 at 4:23 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Perrine Martignoni wrote:
> > Hello,
> >
> > I work on a MPC8347 processor and I found out a problem with
> > rtdm_event_wait(). I reproduce the problem with a simple code :
> >
> > *driver.c* :
> > #include <rtdm/rtdm_driver.h>
> >
> > MODULE_AUTHOR("P.Martignoni");
> > MODULE_LICENSE("GPL");
> >
> > #define DEV_FILE_NAME "DspDev"
> > #define DRV_NAME "DspDrv"
> >
> > #define DEV_FILE_DSP "dspdev0"
> >
> > static rtdm_event_t s_ReadEvent;
> >
> > static int Open(struct rtdm_dev_context *p_Context,
> > rtdm_user_info_t *p_UserInfo,
> > int Oflags)
> > {
> > int ret = 0;
> >
> > rtdm_event_init(&s_ReadEvent,0);
> >
> > // generates an error : Oops : Kernel access of bad area, sig : 11
> [#1]
> > rtdm_event_wait(&s_ReadEvent);
>
> General advice: switch on XENO_OPT_DEBUG_RTDM (and IPIPE_DEBUG_CONTEXT)
> to catch service invocations from a wrong context, like here.
>
> Your mistake: calling a blocking Xenomai services from non-rt context
> (see your registration of Open in t_IdspDevice).
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help