All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] Problem Handling GPIO interrupts
@ 2013-03-02  4:47 Jonathan Wallace
  2013-03-02  5:35 ` Gilles Chanteperdrix
  2013-03-02  5:41 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 6+ messages in thread
From: Jonathan Wallace @ 2013-03-02  4:47 UTC (permalink / raw)
  To: xenomai

Hi all,

I'm trying to get a small variation of the usr_irq.c example working,
but rt_intr_wait keeps returning -38 without blocking and perror
prints success. If I don't let it print anything (so it will run
faster) it seg faults after about 4 or 5 seconds, calling rt_intr_wait
in an infinite loop during that time.

I'm also having an issue where if I run the program from an SSH
session, rt_task_create returns EPERM, but will return a success if I
run the program from the serial console. I can only assume there's
some difference in the shell processes at the kernel level, but if
there's a way to get around this, I would love to know too.

A little background about the IRQ, because I could have this all wrong
too... I exported a gpio pin and echoed "falling" into the edge file
in sysfs. This added an entry in /procs/interrupts "205:         42
  GPIO  gpiolib" The number 42, increments every time I press my
button to cause an physical interrupt on the pin so I know its at
least working up to that point. I used this number 205 as the argument
to rt_intr_create, but I'm not sure that was the right thing to do.

Here's the complete source code, its not complicated at all.

#include <sys/mman.h>
#include <errno.h>
#include <signal.h>
#include <native/task.h>
#include <native/intr.h>
#define IRQ_NUMBER 205          /* GPIOLIB interrupt */
#define TASK_PRIO  99           /* Highest RT priority */
#define TASK_MODE  0            /* No flags */
#define TASK_STKSZ 0            /* Stack size (use default one) */

RT_INTR intr_desc;
RT_TASK server_desc;

void irq_server(void *cookie)
{
        int err;
        for (;;) {
                /* Wait for the next interrupt */

                /* Always returns -38 instantly*/
                err = rt_intr_wait(&intr_desc, TM_INFINITE);

                if (err > 0) {
                        printf("Interrupt rcvd! %d events\n", err);
                } else switch (err) {
                case -ETIMEDOUT:
                        printf("Timed out waiting\n");
                        break;
                case -EINVAL:
                        printf("Inavlid argument\n");
                        break;
                case -EIDRM:
                        printf("Deleted object\n");
                        break;
                case -EINTR:
                        printf("unblocked\n");
                        break;
                case 0:
                        break;
                default:
                        printf("%d\n",err);
                        perror("irq_server");
                        break;
                }
        }
}

void catch_signal(int sig)
{
}

int main(int argc, char *argv[])
{
        signal(SIGTERM, catch_signal);
        signal(SIGINT, catch_signal);
        int err;

        mlockall(MCL_CURRENT | MCL_FUTURE);

        printf("Registering interrupt...\n");
        err = rt_intr_create(&intr_desc, "MyIrq", IRQ_NUMBER, 0);
        switch (err) {
        case -ENOMEM:
                printf("No mem!\n");
                goto fail1;
                break;
        case -EBUSY:
                printf("Busy!\n");
                goto fail1;
                break;
        default:
                break;
        }

        printf("Creating task...\n");
        err = rt_task_create(&server_desc,
                             "MyIrqServer",
                             TASK_STKSZ, TASK_PRIO, TASK_MODE);
        switch (err) {
        case -ENOMEM:
                printf("No mem!\n");
                goto fail2;
                break;
        case -EEXIST:
                printf("Name is already in use\n");
                goto fail2;
                break;
        case -EPERM:
                printf("EPERM, called from async context!\n");
                goto fail2;
                break;
        case 0: /* No error */
                printf("Starting task...\n");
                rt_task_start(&server_desc, &irq_server, NULL);
                break;
        }
        pause();
fail2:
        rt_task_delete(&server_desc);
fail1:
        rt_intr_delete(&intr_desc);
}


-Jon Wallace


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai] Problem Handling GPIO interrupts
  2013-03-02  4:47 [Xenomai] Problem Handling GPIO interrupts Jonathan Wallace
@ 2013-03-02  5:35 ` Gilles Chanteperdrix
  2013-03-02  5:41 ` Gilles Chanteperdrix
  1 sibling, 0 replies; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-03-02  5:35 UTC (permalink / raw)
  To: Jonathan Wallace; +Cc: xenomai

On 03/02/2013 05:47 AM, Jonathan Wallace wrote:

> Hi all,
> 
> I'm trying to get a small variation of the usr_irq.c example working,
> but rt_intr_wait keeps returning -38 without blocking and perror
> prints success. If I don't let it print anything (so it will run
> faster) it seg faults after about 4 or 5 seconds, calling rt_intr_wait
> in an infinite loop during that time.
> 
> I'm also having an issue where if I run the program from an SSH
> session, rt_task_create returns EPERM, but will return a success if I
> run the program from the serial console. I can only assume there's
> some difference in the shell processes at the kernel level, but if
> there's a way to get around this, I would love to know too.
> 
> A little background about the IRQ, because I could have this all wrong
> too... I exported a gpio pin and echoed "falling" into the edge file
> in sysfs. This added an entry in /procs/interrupts "205:         42
>   GPIO  gpiolib" The number 42, increments every time I press my
> button to cause an physical interrupt on the pin so I know its at
> least working up to that point. I used this number 205 as the argument
> to rt_intr_create, but I'm not sure that was the right thing to do.
> 
> Here's the complete source code, its not complicated at all.
> 
> #include <sys/mman.h>
> #include <errno.h>
> #include <signal.h>
> #include <native/task.h>
> #include <native/intr.h>
> #define IRQ_NUMBER 205          /* GPIOLIB interrupt */
> #define TASK_PRIO  99           /* Highest RT priority */
> #define TASK_MODE  0            /* No flags */
> #define TASK_STKSZ 0            /* Stack size (use default one) */
> 
> RT_INTR intr_desc;
> RT_TASK server_desc;
> 
> void irq_server(void *cookie)
> {
>         int err;
>         for (;;) {
>                 /* Wait for the next interrupt */
> 
>                 /* Always returns -38 instantly*/
>                 err = rt_intr_wait(&intr_desc, TM_INFINITE);
> 
>                 if (err > 0) {
>                         printf("Interrupt rcvd! %d events\n", err);
>                 } else switch (err) {
>                 case -ETIMEDOUT:
>                         printf("Timed out waiting\n");
>                         break;
>                 case -EINVAL:
>                         printf("Inavlid argument\n");
>                         break;
>                 case -EIDRM:
>                         printf("Deleted object\n");
>                         break;
>                 case -EINTR:
>                         printf("unblocked\n");
>                         break;
>                 case 0:
>                         break;
>                 default:
>                         printf("%d\n",err);
>                         perror("irq_server");
>                         break;
>                 }
>         }
> }
> 
> void catch_signal(int sig)
> {
> }
> 
> int main(int argc, char *argv[])
> {
>         signal(SIGTERM, catch_signal);
>         signal(SIGINT, catch_signal);
>         int err;
> 
>         mlockall(MCL_CURRENT | MCL_FUTURE);
> 
>         printf("Registering interrupt...\n");
>         err = rt_intr_create(&intr_desc, "MyIrq", IRQ_NUMBER, 0);
>         switch (err) {
>         case -ENOMEM:
>                 printf("No mem!\n");
>                 goto fail1;
>                 break;
>         case -EBUSY:
>                 printf("Busy!\n");
>                 goto fail1;
>                 break;
>         default:
>                 break;
>         }
> 
>         printf("Creating task...\n");
>         err = rt_task_create(&server_desc,
>                              "MyIrqServer",
>                              TASK_STKSZ, TASK_PRIO, TASK_MODE);
>         switch (err) {
>         case -ENOMEM:
>                 printf("No mem!\n");
>                 goto fail2;
>                 break;
>         case -EEXIST:
>                 printf("Name is already in use\n");
>                 goto fail2;
>                 break;
>         case -EPERM:
>                 printf("EPERM, called from async context!\n");
>                 goto fail2;
>                 break;
>         case 0: /* No error */
>                 printf("Starting task...\n");
>                 rt_task_start(&server_desc, &irq_server, NULL);
>                 break;
>         }
>         pause();
> fail2:
>         rt_task_delete(&server_desc);
> fail1:
>         rt_intr_delete(&intr_desc);
> }
> 
> 
> -Jon Wallace
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
> 



-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai] Problem Handling GPIO interrupts
  2013-03-02  4:47 [Xenomai] Problem Handling GPIO interrupts Jonathan Wallace
  2013-03-02  5:35 ` Gilles Chanteperdrix
@ 2013-03-02  5:41 ` Gilles Chanteperdrix
       [not found]   ` <CAJjOJyaCg0A_wYzew=monnfvjmCWGvc8Y4APXG5fFoarGH9SRw@mail.gmail.com>
  1 sibling, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-03-02  5:41 UTC (permalink / raw)
  To: Jonathan Wallace; +Cc: xenomai

On 03/02/2013 05:47 AM, Jonathan Wallace wrote:

> Hi all,
> 
> I'm trying to get a small variation of the usr_irq.c example working,
> but rt_intr_wait keeps returning -38 without blocking and perror
> prints success. If I don't let it print anything (so it will run


Sorry for the empty reply. The native skin does not use errno, so,
perror will not print anything, rt_intr_wait return value has to be
considered the error itself.

-38 is -ENOSYS, meaning that the kernel does not implement the function.

Indeed, handling interrupts in user-space is deprecated, for this
reason, support is disabled by default in Xenomai kernel.

In order to add support for the rt_intr_* services, you have to enable
CONFIG_XENO_OPT_NATIVE_INTR
in the kernel configuration.


> faster) it seg faults after about 4 or 5 seconds, calling rt_intr_wait
> in an infinite loop during that time.
> 
> I'm also having an issue where if I run the program from an SSH
> session, rt_task_create returns EPERM, but will return a success if I
> run the program from the serial console. I can only assume there's
> some difference in the shell processes at the kernel level, but if
> there's a way to get around this, I would love to know too.


I do not know if this is related, but Xenomai services are by default
only available to the "root" user, so, if you are not loging with ssh as
root user, what you observe is normal. If not, then what you observe is
a new bug. Maybe ssh restrict some capabilities even when logging at root?



> 
> A little background about the IRQ, because I could have this all wrong
> too... I exported a gpio pin and echoed "falling" into the edge file
> in sysfs. This added an entry in /procs/interrupts "205:         42
>   GPIO  gpiolib" The number 42, increments every time I press my
> button to cause an physical interrupt on the pin so I know its at
> least working up to that point. I used this number 205 as the argument
> to rt_intr_create, but I'm not sure that was the right thing to do.


This should probably work. You may have to run rt_intr_enable after
rt_intr_create though.

-- 

                                                                Gilles.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai] Problem Handling GPIO interrupts
       [not found]   ` <CAJjOJyaCg0A_wYzew=monnfvjmCWGvc8Y4APXG5fFoarGH9SRw@mail.gmail.com>
@ 2013-03-02  6:44     ` Gilles Chanteperdrix
  2013-03-03  2:53       ` Jonathan Wallace
  0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-03-02  6:44 UTC (permalink / raw)
  To: Jonathan Wallace; +Cc: Xenomai

On 03/02/2013 07:38 AM, Jonathan Wallace wrote:

> On Fri, Mar 1, 2013 at 9:41 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org
> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>> On 03/02/2013 05:47 AM, Jonathan Wallace wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to get a small variation of the usr_irq.c example working,
>>> but rt_intr_wait keeps returning -38 without blocking and perror
>>> prints success. If I don't let it print anything (so it will run
>>
>>
>> Sorry for the empty reply. The native skin does not use errno, so,
>> perror will not print anything, rt_intr_wait return value has to be
>> considered the error itself.
>>
>> -38 is -ENOSYS, meaning that the kernel does not implement the function.
>>
>> Indeed, handling interrupts in user-space is deprecated, for this
>> reason, support is disabled by default in Xenomai kernel.
>>
>> In order to add support for the rt_intr_* services, you have to enable
>> CONFIG_XENO_OPT_NATIVE_INTR
>> in the kernel configuration.
>>
>>
>>> faster) it seg faults after about 4 or 5 seconds, calling rt_intr_wait
>>> in an infinite loop during that time.
>>>
>>> I'm also having an issue where if I run the program from an SSH
>>> session, rt_task_create returns EPERM, but will return a success if I
>>> run the program from the serial console. I can only assume there's
>>> some difference in the shell processes at the kernel level, but if
>>> there's a way to get around this, I would love to know too.
>>
>>
>> I do not know if this is related, but Xenomai services are by default
>> only available to the "root" user, so, if you are not loging with ssh as
>> root user, what you observe is normal. If not, then what you observe is
>> a new bug. Maybe ssh restrict some capabilities even when logging at root?
>>
>>
>>
>>>
>>> A little background about the IRQ, because I could have this all wrong
>>> too... I exported a gpio pin and echoed "falling" into the edge file
>>> in sysfs. This added an entry in /procs/interrupts "205: 42
>>> GPIO gpiolib" The number 42, increments every time I press my
>>> button to cause an physical interrupt on the pin so I know its at
>>> least working up to that point. I used this number 205 as the argument
>>> to rt_intr_create, but I'm not sure that was the right thing to do.
>>
>>
>> This should probably work. You may have to run rt_intr_enable after
>> rt_intr_create though.
>>
>> --
>>
>> Gilles.
> 
> Oh, the API documentation doesn't list ENOSYS as a possible return value
> for rt_intr_wait, is there a Xenomai version of errno that I should use
> for the definitions of the error codes or are they just part of the
> standard headers?


ENOSYS is defined of errno.h, the error are not returned through the
"errno" variable by native skin services, but directly as negative
values. ENOSYS is a "generic" return value, meaning that a service is
not implemented by the kernel, and generally means that you have to
enable some option in the kernel configuration to enable the service.
Maybe we can document this in TROUBLESHOOTING.

> 
> Either way I'd rather run this in kernel space I thought I'd just
> implement it the easy way if possible to make sure things were working
> on the Xenomai side of things.


You can try to implement this in user-space. Chances are, however, that
handling interrupts in user-space is in fact harder than handling them
in kernel-space.

> 
> For the SSH part, I was root in both terminals, I'll check the ssh group
> permissions though. This is on a beaglebone btw.


Maybe your rootfs has /etc/security/capabilities.conf or
/etc/security/limits.conf ?

(re-adding the list to cc).

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai] Problem Handling GPIO interrupts
  2013-03-02  6:44     ` Gilles Chanteperdrix
@ 2013-03-03  2:53       ` Jonathan Wallace
  2013-03-03  5:30         ` Gilles Chanteperdrix
  0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wallace @ 2013-03-03  2:53 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: Xenomai

On Fri, Mar 1, 2013 at 10:44 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 03/02/2013 07:38 AM, Jonathan Wallace wrote:
>
>> On Fri, Mar 1, 2013 at 9:41 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org
>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>>> On 03/02/2013 05:47 AM, Jonathan Wallace wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm trying to get a small variation of the usr_irq.c example working,
>>>> but rt_intr_wait keeps returning -38 without blocking and perror
>>>> prints success. If I don't let it print anything (so it will run
>>>
>>>
>>> Sorry for the empty reply. The native skin does not use errno, so,
>>> perror will not print anything, rt_intr_wait return value has to be
>>> considered the error itself.
>>>
>>> -38 is -ENOSYS, meaning that the kernel does not implement the function.
>>>
>>> Indeed, handling interrupts in user-space is deprecated, for this
>>> reason, support is disabled by default in Xenomai kernel.
>>>
>>> In order to add support for the rt_intr_* services, you have to enable
>>> CONFIG_XENO_OPT_NATIVE_INTR
>>> in the kernel configuration.
>>>
>>>
>>>> faster) it seg faults after about 4 or 5 seconds, calling rt_intr_wait
>>>> in an infinite loop during that time.
>>>>
>>>> I'm also having an issue where if I run the program from an SSH
>>>> session, rt_task_create returns EPERM, but will return a success if I
>>>> run the program from the serial console. I can only assume there's
>>>> some difference in the shell processes at the kernel level, but if
>>>> there's a way to get around this, I would love to know too.
>>>
>>>
>>> I do not know if this is related, but Xenomai services are by default
>>> only available to the "root" user, so, if you are not loging with ssh as
>>> root user, what you observe is normal. If not, then what you observe is
>>> a new bug. Maybe ssh restrict some capabilities even when logging at root?
>>>
>>>
>>>
>>>>
>>>> A little background about the IRQ, because I could have this all wrong
>>>> too... I exported a gpio pin and echoed "falling" into the edge file
>>>> in sysfs. This added an entry in /procs/interrupts "205: 42
>>>> GPIO gpiolib" The number 42, increments every time I press my
>>>> button to cause an physical interrupt on the pin so I know its at
>>>> least working up to that point. I used this number 205 as the argument
>>>> to rt_intr_create, but I'm not sure that was the right thing to do.
>>>
>>>
>>> This should probably work. You may have to run rt_intr_enable after
>>> rt_intr_create though.
>>>
>>> --
>>>
>>> Gilles.
>>
>> Oh, the API documentation doesn't list ENOSYS as a possible return value
>> for rt_intr_wait, is there a Xenomai version of errno that I should use
>> for the definitions of the error codes or are they just part of the
>> standard headers?
>
>
> ENOSYS is defined of errno.h, the error are not returned through the
> "errno" variable by native skin services, but directly as negative
> values. ENOSYS is a "generic" return value, meaning that a service is
> not implemented by the kernel, and generally means that you have to
> enable some option in the kernel configuration to enable the service.
> Maybe we can document this in TROUBLESHOOTING.
>
>>
>> Either way I'd rather run this in kernel space I thought I'd just
>> implement it the easy way if possible to make sure things were working
>> on the Xenomai side of things.
>
>
> You can try to implement this in user-space. Chances are, however, that
> handling interrupts in user-space is in fact harder than handling them
> in kernel-space.
>
>>
>> For the SSH part, I was root in both terminals, I'll check the ssh group
>> permissions though. This is on a beaglebone btw.
>
>
> Maybe your rootfs has /etc/security/capabilities.conf or
> /etc/security/limits.conf ?
>
> (re-adding the list to cc).
>
> --
>                                                                 Gilles.

I've moved my test app over to a bare-bones module where I can printk
to see if its working, but I can't get it to compile using a simple
Makefile that works for cross-compiling modules that don't #include
Xenomai headers. It quits when it can't find native/task.h. So I ran
make with V=1 and it looks like -Iinclude/xenomai isn't added to the
(enormous) gcc command, which should put native/* in the search path.
I don't know what the "proper" way of adding this to the CFLAGS is so
I thought I'd look at some of the examples in the xenomai source...

I ended up modifying the makefile in
.../xenomai-2.6.2.1/examples/rtdm/driver-api to try and make it
compile just the rtdm examples for my board but the preprocesser isn't
finding the Xenomai headers either and has a few other errors. I ran
this one with V=1 also and it looks like some of the "-I" paths,
including .../include/xenomai, are missing the XENO_DESTDIR prefix so
its looking in my native machine's /lib/modules path instead of the
target's, I don't know how to fix this one either. I can send one or
both of these makefiles if it would help, but if there was an example
with a makefile built for cross-compiling modules, that would make my
life a lot easier.

As far as the SSH permissions issue, I checked the files under
/etc/security and there aren't any policies configured, ssh has a very
minimal config (dropbear server). Let me know if there's anything else
you want me to check, I don't know if there is a bugreporting site,
but I'd be happy to write up a small report on it if you think its
something worth looking into.

-Jon


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xenomai] Problem Handling GPIO interrupts
  2013-03-03  2:53       ` Jonathan Wallace
@ 2013-03-03  5:30         ` Gilles Chanteperdrix
  0 siblings, 0 replies; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-03-03  5:30 UTC (permalink / raw)
  To: Jonathan Wallace; +Cc: Xenomai

On 03/03/2013 03:53 AM, Jonathan Wallace wrote:

> On Fri, Mar 1, 2013 at 10:44 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 03/02/2013 07:38 AM, Jonathan Wallace wrote:
>>
>>> On Fri, Mar 1, 2013 at 9:41 PM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org
>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>>>> On 03/02/2013 05:47 AM, Jonathan Wallace wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm trying to get a small variation of the usr_irq.c example working,
>>>>> but rt_intr_wait keeps returning -38 without blocking and perror
>>>>> prints success. If I don't let it print anything (so it will run
>>>>
>>>>
>>>> Sorry for the empty reply. The native skin does not use errno, so,
>>>> perror will not print anything, rt_intr_wait return value has to be
>>>> considered the error itself.
>>>>
>>>> -38 is -ENOSYS, meaning that the kernel does not implement the function.
>>>>
>>>> Indeed, handling interrupts in user-space is deprecated, for this
>>>> reason, support is disabled by default in Xenomai kernel.
>>>>
>>>> In order to add support for the rt_intr_* services, you have to enable
>>>> CONFIG_XENO_OPT_NATIVE_INTR
>>>> in the kernel configuration.
>>>>
>>>>
>>>>> faster) it seg faults after about 4 or 5 seconds, calling rt_intr_wait
>>>>> in an infinite loop during that time.
>>>>>
>>>>> I'm also having an issue where if I run the program from an SSH
>>>>> session, rt_task_create returns EPERM, but will return a success if I
>>>>> run the program from the serial console. I can only assume there's
>>>>> some difference in the shell processes at the kernel level, but if
>>>>> there's a way to get around this, I would love to know too.
>>>>
>>>>
>>>> I do not know if this is related, but Xenomai services are by default
>>>> only available to the "root" user, so, if you are not loging with ssh as
>>>> root user, what you observe is normal. If not, then what you observe is
>>>> a new bug. Maybe ssh restrict some capabilities even when logging at root?
>>>>
>>>>
>>>>
>>>>>
>>>>> A little background about the IRQ, because I could have this all wrong
>>>>> too... I exported a gpio pin and echoed "falling" into the edge file
>>>>> in sysfs. This added an entry in /procs/interrupts "205: 42
>>>>> GPIO gpiolib" The number 42, increments every time I press my
>>>>> button to cause an physical interrupt on the pin so I know its at
>>>>> least working up to that point. I used this number 205 as the argument
>>>>> to rt_intr_create, but I'm not sure that was the right thing to do.
>>>>
>>>>
>>>> This should probably work. You may have to run rt_intr_enable after
>>>> rt_intr_create though.
>>>>
>>>> --
>>>>
>>>> Gilles.
>>>
>>> Oh, the API documentation doesn't list ENOSYS as a possible return value
>>> for rt_intr_wait, is there a Xenomai version of errno that I should use
>>> for the definitions of the error codes or are they just part of the
>>> standard headers?
>>
>>
>> ENOSYS is defined of errno.h, the error are not returned through the
>> "errno" variable by native skin services, but directly as negative
>> values. ENOSYS is a "generic" return value, meaning that a service is
>> not implemented by the kernel, and generally means that you have to
>> enable some option in the kernel configuration to enable the service.
>> Maybe we can document this in TROUBLESHOOTING.
>>
>>>
>>> Either way I'd rather run this in kernel space I thought I'd just
>>> implement it the easy way if possible to make sure things were working
>>> on the Xenomai side of things.
>>
>>
>> You can try to implement this in user-space. Chances are, however, that
>> handling interrupts in user-space is in fact harder than handling them
>> in kernel-space.
>>
>>>
>>> For the SSH part, I was root in both terminals, I'll check the ssh group
>>> permissions though. This is on a beaglebone btw.
>>
>>
>> Maybe your rootfs has /etc/security/capabilities.conf or
>> /etc/security/limits.conf ?
>>
>> (re-adding the list to cc).
>>
>> --
>>                                                                 Gilles.
> 
> I've moved my test app over to a bare-bones module where I can printk
> to see if its working, but I can't get it to compile using a simple
> Makefile that works for cross-compiling modules that don't #include
> Xenomai headers. It quits when it can't find native/task.h. So I ran
> make with V=1 and it looks like -Iinclude/xenomai isn't added to the
> (enormous) gcc command, which should put native/* in the search path.
> I don't know what the "proper" way of adding this to the CFLAGS is so
> I thought I'd look at some of the examples in the xenomai source...


You have to use EXTRA_CFLAGS. Here is what I use to built test modules:

obj-m := test-module.o
test-module-objs := code.o
EXTRA_CFLAGS += -Iinclude/xenomai

> 
> I ended up modifying the makefile in
> .../xenomai-2.6.2.1/examples/rtdm/driver-api to try and make it
> compile just the rtdm examples for my board but the preprocesser isn't
> finding the Xenomai headers either and has a few other errors. I ran
> this one with V=1 also and it looks like some of the "-I" paths,
> including .../include/xenomai,


Well, if you are using the kernel sources, they must have been prepared
with "prepare-kernel", if you are using the linux-image debian packet,
you have to install the linux-headers packet.


> are missing the XENO_DESTDIR prefix so
> its looking in my native machine's /lib/modules path instead of the
> target's, I don't know how to fix this one either. I can send one or
> both of these makefiles if it would help, but if there was an example
> with a makefile built for cross-compiling modules, that would make my
> life a lot easier.


See:
http://www.xenomai.org/index.php/Examples

> 
> As far as the SSH permissions issue, I checked the files under
> /etc/security and there aren't any policies configured, ssh has a very
> minimal config (dropbear server). Let me know if there's anything else
> you want me to check, I don't know if there is a bugreporting site,
> but I'd be happy to write up a small report on it if you think its
> something worth looking into.


The mailing list is the "bug reporting" site. You can write your report
as an email, you can add attachments, they are scrubbed and not sent to
every subscriber.
-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-03-03  5:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-02  4:47 [Xenomai] Problem Handling GPIO interrupts Jonathan Wallace
2013-03-02  5:35 ` Gilles Chanteperdrix
2013-03-02  5:41 ` Gilles Chanteperdrix
     [not found]   ` <CAJjOJyaCg0A_wYzew=monnfvjmCWGvc8Y4APXG5fFoarGH9SRw@mail.gmail.com>
2013-03-02  6:44     ` Gilles Chanteperdrix
2013-03-03  2:53       ` Jonathan Wallace
2013-03-03  5:30         ` Gilles Chanteperdrix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.