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

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

[Saravanan S]

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

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??

What  is the purpose of this feature of allowing user space handling of
interrupts.Can a user space driver be written using this???

Thanks in advance.

With regards,

S Saravanan

[-- Attachment #2: Type: text/html, Size: 573 bytes --]

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

[Philippe Gerum]

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.

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.

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


-- 
Philippe.

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

[Saravanan S]

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

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....



> 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.


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

[-- Attachment #2: Type: text/html, Size: 3047 bytes --]

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

[Philippe Gerum]

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.

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

[Saravanan S]

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

On Fri, Feb 5, 2010 at 10:13 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> 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.
>

RTDM is the right approach i agree.I currently want real time driver for a
Qlogic fibre channel Host Bus Adapter PCI express card.With no experience in
writing drivers i will have a tough time.Anyway i will try to start on this
path.Thanks.


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

[-- Attachment #2: Type: text/html, Size: 6179 bytes --]

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

[Stefan Kisdaroczi]

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

Hi,

Am 04.02.2010 16:51, schrieb Saravanan S:
> 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!!!!!

The rt_intr_* interface is disabled by default in the kernel configuration, please check.
That would mean that rt_intr_wait returns immediately, now look at this loop from user_irq.c:
    for (;;) {

       /* Wait for the next interrupt on channel #7. */
       err = rt_intr_wait(&intr_desc,TM_INFINITE);

       if (!err) {
           /* Process interrupt. */
       }

> What am i doing wrong??
> 
> What  is the purpose of this feature of allowing user space handling of
> interrupts.Can a user space driver be written using this???

You should use the rtdm interface for drivers.

Regards Stefan


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

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

[Saravanan S]

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

On Thu, Feb 4, 2010 at 9:46 PM, Stefan Kisdaroczi <kisda@domain.hid> wrote:

> Hi,
>
> Am 04.02.2010 16:51, schrieb Saravanan S:
> > 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!!!!!
>
> The rt_intr_* interface is disabled by default in the kernel configuration,
> please check.
> That would mean that rt_intr_wait returns immediately, now look at this
> loop from user_irq.c:
>    for (;;) {
>
>       /* Wait for the next interrupt on channel #7. */
>       err = rt_intr_wait(&intr_desc,TM_INFINITE);
>
>       if (!err) {
>           /* Process interrupt. */
>        }
>
>
Can you please indicate which variable in the kernel config controls that
setting???


> > What am i doing wrong??
> >
> > What  is the purpose of this feature of allowing user space handling of
> > interrupts.Can a user space driver be written using this???
>
> You should use the rtdm interface for drivers.
>

I know very little in kernel programming so thought it would be easier to
process interrrupts in user space.....


>
> Regards Stefan
>
>
Regards

S Saravanan

[-- Attachment #2: Type: text/html, Size: 2122 bytes --]

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

[Stefan Kisdaroczi]

Saravanan S schrieb:
> 
> 
> On Thu, Feb 4, 2010 at 9:46 PM, Stefan Kisdaroczi <kisda@domain.hid
> <mailto:kisda@domain.hid>> wrote:
> 
>     Hi,
> 
>     Am 04.02.2010 16:51, schrieb Saravanan S:
>     > 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!!!!!
> 
>     The rt_intr_* interface is disabled by default in the kernel
>     configuration, please check.
>     That would mean that rt_intr_wait returns immediately, now look at
>     this loop from user_irq.c:
>        for (;;) {
> 
>           /* Wait for the next interrupt on channel #7. */
>           err = rt_intr_wait(&intr_desc,TM_INFINITE);
> 
>           if (!err) {
>               /* Process interrupt. */
>           }
> 
> 
> Can you please indicate which variable in the kernel config controls
> that setting???

The variable name in the config file is: CONFIG_XENO_OPT_NATIVE_INTR

If you use 'make menuconfig' to configure the kernel,
from the main menu, go to:
 Real-time sub-system ---> Interfaces ---> Native API
 There is a option called 'Interrupts' at the end of the list

>     > What am i doing wrong??
>     >
>     > What  is the purpose of this feature of allowing user space
>     handling of
>     > interrupts.Can a user space driver be written using this???
> 
>     You should use the rtdm interface for drivers.
> 
> 
> I know very little in kernel programming so thought it would be easier
> to process interrrupts in user space.....

look here for starting points:
  https://mail.gna.org/public/xenomai-help/2009-05/msg00168.html


Stefan