On Mon, Nov 17, 2014 at 02:12:37PM -0500, Lennart Sorensen wrote:
> On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> > For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> > deleting, enabling or disabling an IRQ channel must be done from
> > secondary mode. The syscall mode bits for these native API calls are
> > wrong, should be as follows instead:
> >
> > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> > index 950b092..dff7f4d 100644
> > --- a/ksrc/skins/native/syscall.c
> > +++ b/ksrc/skins/native/syscall.c
> > @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
> > [__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
> > [__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
> > [__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> > - [__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> > + [__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
> > [__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> > - [__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> > + [__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
> > [__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> > - [__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> > - [__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> > + [__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> > + [__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
> > [__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
> > [__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
> > [__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},
>
> Are you sure all 4 of those had to change? I can see intr_create and
> intr_delete, but intr_enable and disable? We are seeing insane latency
> from realtime irqs on the omap gpio irqs (a few ms response to an irq).
> Of course it could be the gpio irq is just doing something wrong.
> Not sure yet. Of course before doing this change we sometimes saw it
> take close to 1s to call the realtime irq handler which made no sense
> at all. gic interrupts are working as expected and see no delays that
> we are aware of at least.
Well, have you tried triggering an I-pipe tracer trace to see what
happens in the interval?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
