* [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application.
@ 2010-02-10 17:56 Michael Buksas
2010-02-10 18:31 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Michael Buksas @ 2010-02-10 17:56 UTC (permalink / raw)
To: xenomai
I'm porting a VxWorks application to Xenomai/SOLO and getting
S_memLib_NOT_ENOUGH_MEMORY errors from taskSpawn.
I'm currently running on a desktop Linux system, so I doubt physical
memory is an issue. Rather, I think it's the allocation of memory for
tasks, and my crushing ignorance about how to do the same.
For example, does this occur when the memory needs of the task exceed
the stack size argument to taskSpawn? Increasing this value does not
appear to help.
Can anyone suggest how to further diagnose the memory problem?
And to address the broader question, where should a raw beginner at
embedded programming go for documentation on Xenomai/SOLO and guidance
for the porting process?
Thanks in advance,
Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application.
2010-02-10 17:56 [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application Michael Buksas
@ 2010-02-10 18:31 ` Philippe Gerum
2010-02-10 22:22 ` Michael Buksas
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2010-02-10 18:31 UTC (permalink / raw)
To: Michael Buksas; +Cc: xenomai
On Wed, 2010-02-10 at 10:56 -0700, Michael Buksas wrote:
> I'm porting a VxWorks application to Xenomai/SOLO and getting
> S_memLib_NOT_ENOUGH_MEMORY errors from taskSpawn.
>
> I'm currently running on a desktop Linux system, so I doubt physical
> memory is an issue. Rather, I think it's the allocation of memory for
> tasks, and my crushing ignorance about how to do the same.
>
> For example, does this occur when the memory needs of the task exceed
> the stack size argument to taskSpawn? Increasing this value does not
> appear to help.
>
> Can anyone suggest how to further diagnose the memory problem?
Sloppy code at work in the emulator. Could you apply this patch and
check the actual return code? If -EPERM, then make sure to run your app
with root privileges, since the emulator attempts to create SCHED_FIFO
threads.
diff --git a/vxworks/taskLib.c b/vxworks/taskLib.c
index a9e12e7..4db2c66 100644
--- a/vxworks/taskLib.c
+++ b/vxworks/taskLib.c
@@ -327,7 +327,7 @@ static STATUS __taskInit(struct wind_task *task,
ret = pthread_create(&thid, &thattr, &task_trampoline, task);
pthread_attr_destroy(&thattr);
if (ret) {
- errno = S_memLib_NOT_ENOUGH_MEMORY;
+ errno = ret == -EAGAIN ? S_memLib_NOT_ENOUGH_MEMORY : ret;
return ERROR;
}
>
> And to address the broader question, where should a raw beginner at
> embedded programming go for documentation on Xenomai/SOLO and guidance
> for the porting process?
>
> Thanks in advance,
> Mike
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application.
2010-02-10 18:31 ` Philippe Gerum
@ 2010-02-10 22:22 ` Michael Buksas
2010-02-11 17:05 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Michael Buksas @ 2010-02-10 22:22 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe,
After the patch, all of the failing tasks return 22: Invalid Argument.
I can't find anything unique about these three tasks among the many
others, however. They're all using 0x8 for options, have similar stack
sizes and priorities.
Thanks,
Mike
Philippe Gerum wrote:
> On Wed, 2010-02-10 at 10:56 -0700, Michael Buksas wrote:
>> I'm porting a VxWorks application to Xenomai/SOLO and getting
>> S_memLib_NOT_ENOUGH_MEMORY errors from taskSpawn.
>>
>> I'm currently running on a desktop Linux system, so I doubt physical
>> memory is an issue. Rather, I think it's the allocation of memory for
>> tasks, and my crushing ignorance about how to do the same.
>>
>> For example, does this occur when the memory needs of the task exceed
>> the stack size argument to taskSpawn? Increasing this value does not
>> appear to help.
>>
>> Can anyone suggest how to further diagnose the memory problem?
>
> Sloppy code at work in the emulator. Could you apply this patch and
> check the actual return code? If -EPERM, then make sure to run your app
> with root privileges, since the emulator attempts to create SCHED_FIFO
> threads.
>
> diff --git a/vxworks/taskLib.c b/vxworks/taskLib.c
> index a9e12e7..4db2c66 100644
> --- a/vxworks/taskLib.c
> +++ b/vxworks/taskLib.c
> @@ -327,7 +327,7 @@ static STATUS __taskInit(struct wind_task *task,
> ret = pthread_create(&thid, &thattr, &task_trampoline, task);
> pthread_attr_destroy(&thattr);
> if (ret) {
> - errno = S_memLib_NOT_ENOUGH_MEMORY;
> + errno = ret == -EAGAIN ? S_memLib_NOT_ENOUGH_MEMORY : ret;
> return ERROR;
> }
>
>
>> And to address the broader question, where should a raw beginner at
>> embedded programming go for documentation on Xenomai/SOLO and guidance
>> for the porting process?
>>
>> Thanks in advance,
>> Mike
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application.
2010-02-10 22:22 ` Michael Buksas
@ 2010-02-11 17:05 ` Philippe Gerum
2010-02-11 23:04 ` Michael Buksas
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2010-02-11 17:05 UTC (permalink / raw)
To: Michael Buksas; +Cc: xenomai
On Wed, 2010-02-10 at 15:22 -0700, Michael Buksas wrote:
> Philippe,
>
> After the patch, all of the failing tasks return 22: Invalid Argument.
>
> I can't find anything unique about these three tasks among the many
> others, however. They're all using 0x8 for options, have similar stack
> sizes and priorities.
Could you post the failing taskSpawn() call from your application, so
that I could have a look at the argument list?
Additionally, you can use GDB to see what goes wrong; passing
--enable-debug to the configure script will get you the debugging
symbols into the emulator library, and will also disable compiler
optimizations. Then, you should be able to trace the __taskInit()
routine there by setting a breakpoint, and see which statement actually
returns EINVAL.
>
> Thanks,
> Mike
>
>
> Philippe Gerum wrote:
> > On Wed, 2010-02-10 at 10:56 -0700, Michael Buksas wrote:
> >> I'm porting a VxWorks application to Xenomai/SOLO and getting
> >> S_memLib_NOT_ENOUGH_MEMORY errors from taskSpawn.
> >>
> >> I'm currently running on a desktop Linux system, so I doubt physical
> >> memory is an issue. Rather, I think it's the allocation of memory for
> >> tasks, and my crushing ignorance about how to do the same.
> >>
> >> For example, does this occur when the memory needs of the task exceed
> >> the stack size argument to taskSpawn? Increasing this value does not
> >> appear to help.
> >>
> >> Can anyone suggest how to further diagnose the memory problem?
> >
> > Sloppy code at work in the emulator. Could you apply this patch and
> > check the actual return code? If -EPERM, then make sure to run your app
> > with root privileges, since the emulator attempts to create SCHED_FIFO
> > threads.
> >
> > diff --git a/vxworks/taskLib.c b/vxworks/taskLib.c
> > index a9e12e7..4db2c66 100644
> > --- a/vxworks/taskLib.c
> > +++ b/vxworks/taskLib.c
> > @@ -327,7 +327,7 @@ static STATUS __taskInit(struct wind_task *task,
> > ret = pthread_create(&thid, &thattr, &task_trampoline, task);
> > pthread_attr_destroy(&thattr);
> > if (ret) {
> > - errno = S_memLib_NOT_ENOUGH_MEMORY;
> > + errno = ret == -EAGAIN ? S_memLib_NOT_ENOUGH_MEMORY : ret;
> > return ERROR;
> > }
> >
> >
> >> And to address the broader question, where should a raw beginner at
> >> embedded programming go for documentation on Xenomai/SOLO and guidance
> >> for the porting process?
> >>
> >> Thanks in advance,
> >> Mike
> >>
> >>
> >> _______________________________________________
> >> Xenomai-help mailing list
> >> Xenomai-help@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-help
> >
> >
>
>
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application.
2010-02-11 17:05 ` Philippe Gerum
@ 2010-02-11 23:04 ` Michael Buksas
2010-02-11 23:20 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Michael Buksas @ 2010-02-11 23:04 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe,
Turns out, I was trying to spawn tasks with a priority of 97. This is
translated into a SCHED_FIFO priority of zero, causing pthread_create to
complain.
I can't recall where I got the impression that the supported range of
VxWorks priorities was 1..97 instead of 96. I think it appeared in a
warning message I produced earlier in this porting process, but I can't
reproduce it now.
Thanks again,
Mike
Philippe Gerum wrote:
> On Wed, 2010-02-10 at 15:22 -0700, Michael Buksas wrote:
>> Philippe,
>>
>> After the patch, all of the failing tasks return 22: Invalid Argument.
>>
>> I can't find anything unique about these three tasks among the many
>> others, however. They're all using 0x8 for options, have similar stack
>> sizes and priorities.
>
> Could you post the failing taskSpawn() call from your application, so
> that I could have a look at the argument list?
>
> Additionally, you can use GDB to see what goes wrong; passing
> --enable-debug to the configure script will get you the debugging
> symbols into the emulator library, and will also disable compiler
> optimizations. Then, you should be able to trace the __taskInit()
> routine there by setting a breakpoint, and see which statement actually
> returns EINVAL.
>
>> Thanks,
>> Mike
>>
>>
>> Philippe Gerum wrote:
>>> On Wed, 2010-02-10 at 10:56 -0700, Michael Buksas wrote:
>>>> I'm porting a VxWorks application to Xenomai/SOLO and getting
>>>> S_memLib_NOT_ENOUGH_MEMORY errors from taskSpawn.
>>>>
>>>> I'm currently running on a desktop Linux system, so I doubt physical
>>>> memory is an issue. Rather, I think it's the allocation of memory for
>>>> tasks, and my crushing ignorance about how to do the same.
>>>>
>>>> For example, does this occur when the memory needs of the task exceed
>>>> the stack size argument to taskSpawn? Increasing this value does not
>>>> appear to help.
>>>>
>>>> Can anyone suggest how to further diagnose the memory problem?
>>> Sloppy code at work in the emulator. Could you apply this patch and
>>> check the actual return code? If -EPERM, then make sure to run your app
>>> with root privileges, since the emulator attempts to create SCHED_FIFO
>>> threads.
>>>
>>> diff --git a/vxworks/taskLib.c b/vxworks/taskLib.c
>>> index a9e12e7..4db2c66 100644
>>> --- a/vxworks/taskLib.c
>>> +++ b/vxworks/taskLib.c
>>> @@ -327,7 +327,7 @@ static STATUS __taskInit(struct wind_task *task,
>>> ret = pthread_create(&thid, &thattr, &task_trampoline, task);
>>> pthread_attr_destroy(&thattr);
>>> if (ret) {
>>> - errno = S_memLib_NOT_ENOUGH_MEMORY;
>>> + errno = ret == -EAGAIN ? S_memLib_NOT_ENOUGH_MEMORY : ret;
>>> return ERROR;
>>> }
>>>
>>>
>>>> And to address the broader question, where should a raw beginner at
>>>> embedded programming go for documentation on Xenomai/SOLO and guidance
>>>> for the porting process?
>>>>
>>>> Thanks in advance,
>>>> Mike
>>>>
>>>>
>>>> _______________________________________________
>>>> Xenomai-help mailing list
>>>> Xenomai-help@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-help
>>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application.
2010-02-11 23:04 ` Michael Buksas
@ 2010-02-11 23:20 ` Philippe Gerum
0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2010-02-11 23:20 UTC (permalink / raw)
To: Michael Buksas; +Cc: xenomai
On Thu, 2010-02-11 at 16:04 -0700, Michael Buksas wrote:
> Philippe,
>
> Turns out, I was trying to spawn tasks with a priority of 97. This is
> translated into a SCHED_FIFO priority of zero, causing pthread_create to
> complain.
>
> I can't recall where I got the impression that the supported range of
> VxWorks priorities was 1..97 instead of 96.
In the README file. Which is still correct. The problem stems from the
translation done in wind_task_normalize_priority(), which wrongly
assumes that POSIX priority 0 is available for mapping VxWorks priority
97. Will fix. Thanks for the heads up.
> I think it appeared in a
> warning message I produced earlier in this porting process, but I can't
> reproduce it now.
>
> Thanks again,
> Mike
>
> Philippe Gerum wrote:
> > On Wed, 2010-02-10 at 15:22 -0700, Michael Buksas wrote:
> >> Philippe,
> >>
> >> After the patch, all of the failing tasks return 22: Invalid Argument.
> >>
> >> I can't find anything unique about these three tasks among the many
> >> others, however. They're all using 0x8 for options, have similar stack
> >> sizes and priorities.
> >
> > Could you post the failing taskSpawn() call from your application, so
> > that I could have a look at the argument list?
> >
> > Additionally, you can use GDB to see what goes wrong; passing
> > --enable-debug to the configure script will get you the debugging
> > symbols into the emulator library, and will also disable compiler
> > optimizations. Then, you should be able to trace the __taskInit()
> > routine there by setting a breakpoint, and see which statement actually
> > returns EINVAL.
> >
> >> Thanks,
> >> Mike
> >>
> >>
> >> Philippe Gerum wrote:
> >>> On Wed, 2010-02-10 at 10:56 -0700, Michael Buksas wrote:
> >>>> I'm porting a VxWorks application to Xenomai/SOLO and getting
> >>>> S_memLib_NOT_ENOUGH_MEMORY errors from taskSpawn.
> >>>>
> >>>> I'm currently running on a desktop Linux system, so I doubt physical
> >>>> memory is an issue. Rather, I think it's the allocation of memory for
> >>>> tasks, and my crushing ignorance about how to do the same.
> >>>>
> >>>> For example, does this occur when the memory needs of the task exceed
> >>>> the stack size argument to taskSpawn? Increasing this value does not
> >>>> appear to help.
> >>>>
> >>>> Can anyone suggest how to further diagnose the memory problem?
> >>> Sloppy code at work in the emulator. Could you apply this patch and
> >>> check the actual return code? If -EPERM, then make sure to run your app
> >>> with root privileges, since the emulator attempts to create SCHED_FIFO
> >>> threads.
> >>>
> >>> diff --git a/vxworks/taskLib.c b/vxworks/taskLib.c
> >>> index a9e12e7..4db2c66 100644
> >>> --- a/vxworks/taskLib.c
> >>> +++ b/vxworks/taskLib.c
> >>> @@ -327,7 +327,7 @@ static STATUS __taskInit(struct wind_task *task,
> >>> ret = pthread_create(&thid, &thattr, &task_trampoline, task);
> >>> pthread_attr_destroy(&thattr);
> >>> if (ret) {
> >>> - errno = S_memLib_NOT_ENOUGH_MEMORY;
> >>> + errno = ret == -EAGAIN ? S_memLib_NOT_ENOUGH_MEMORY : ret;
> >>> return ERROR;
> >>> }
> >>>
> >>>
> >>>> And to address the broader question, where should a raw beginner at
> >>>> embedded programming go for documentation on Xenomai/SOLO and guidance
> >>>> for the porting process?
> >>>>
> >>>> Thanks in advance,
> >>>> Mike
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Xenomai-help mailing list
> >>>> Xenomai-help@domain.hid
> >>>> https://mail.gna.org/listinfo/xenomai-help
> >>>
> >>
>
--
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-02-11 23:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-10 17:56 [Xenomai-help] S_memLib_NOT_ENOUGH_MEMORY error in porting VxWorks application Michael Buksas
2010-02-10 18:31 ` Philippe Gerum
2010-02-10 22:22 ` Michael Buksas
2010-02-11 17:05 ` Philippe Gerum
2010-02-11 23:04 ` Michael Buksas
2010-02-11 23:20 ` Philippe Gerum
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.