Re: [Xenomai-help] User interrupt handling in Xenomai running into probs

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2010-02-05 at 21:46 +0530, Saravanan S wrote:
> 
> 
> On Thu, Feb 4, 2010 at 9:44 PM, Philippe Gerum <rpm@xenomai.org>
> wrote:
>         On Thu, 2010-02-04 at 21:21 +0530, Saravanan S wrote:
>         > Hi,
>         >
>         >     I tried to implement the hardware interrupt handling
>         feature of
>         > xenomai in user space.I read the native-api document and ran
>         the
>         > user_irq.c program with one change ,i tried to intercept the
>         eth0
>         > interrupt on my system(using interrupt number from
>         > cat /proc/interrupts).When i ran the program the system
>         froze!!!!!
>         >
>         > What am i doing wrong??
>         
>         
>         The thing is that your tiny little change has some impact. You
>         just
>         can't intercept a random interrupt without knowing how it
>         interacts with
>         the Linux kernel, and expect this to work.
>         
>         The Linux NIC driver won't get interrupts because of this,
>         since
>         usr_irq.c does not care of propagating them to the standard
>         kernel, so
>         your device is likely going to bury your box under an
>         interrupt storm.
> 
> To prevent that i used (as given in  native-api document) the option
> I_PROPAGATE while creating the interrupt  object which is supposed to
> forward the interrupt to the kernel after ADEOS services it but still
> the system froze....

This won't be enough. I'm telling you that you should first understand
how intercepting an interrupt in a high priority domain like Xenomai
could (badly) interact with the kernel.

What if your IRQ is level-triggered?
- Xenomai grabs the incoming IRQ, pends it for later processing by Linux
- Your ethernet device keeps chiming in, leaving the interrupt signaled,
because your sample task did not care of clearing the cause of that IRQ.

What do you think will happen next, when interrupts are enabled for
Linux later, or even by Xenomai upon return from its own handler? The
NIC driver won't have the opportunity to run its ISR, because it's
already too late: you have been stormed by interrupts from your ethernet
device.

That could even happen with edge-triggered IRQs, depending on the
device.

I should have added the following in my previous reply: sharing IRQs
between the Linux and Xenomai domains is wrong. All wrong. This is a
limitation induced by the co-kernel design. That is the reason why
usr_irq.c, which is x86-biased, hooks IRQ #7. This one is not associated
with an I/O device. This also explains why changing this to any random
I/O device IRQ number is triggering the issue.

>  
>         What is in snippets/ is not meant to be run blindly. Those are
>         pieces of
>         code to illustrate the use of services in a general way, not
>         examples
>         tailored to run on any platform, not even yours.
>         
>         Read the "Life with Adeos" doc to understand why it can't work
>         the way
>         you did it.
>         
>         >
>         > What  is the purpose of this feature of allowing user space
>         handling
>         > of interrupts.Can a user space driver be written using
>         this???
>         >
>         
>         
>         Sure. When done properly.
> 
> I want to experiment with this feature and need your help on how to do
> it properly.I have read the "Life with Adeos" document. 
> 

Ok, the best help I can give is: forget about doing this. Write a RTDM
device driver in kernel space, to serve a RT app in userland.

Indeed this set of API services to process IRQs in userland is there,
but kept mostly for legacy reasons. But I would not recommend to use
them these days. At all. RTDM is your friend. Really.

> 
>         
>         > Thanks in advance.
>         >
>         > With regards,
>         >
>         > S Saravanan
>         
>         > _______________________________________________
>         > Xenomai-help mailing list
>         > Xenomai-help@domain.hid
>         > https://mail.gna.org/listinfo/xenomai-help
>         
>         
>         --
>         Philippe.
>         
>         
> 


-- 
Philippe.