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