First of all, I'm not sure if that 8K of stack is enough on
PPC with 2.4, on x86 over 2.6 it isn't. The native skin picks
PTHREAD_STACK_MIN*4 for you by default. Is this too much?
Unless dealing with dozens of
*simple* threads, reducing this makes no sense to me.
?? Greping for
memset should work with Xenomai heaps, I suspect your problem
is rather that the memory is not really allocated until you
memset it, which fails when no memory is available. In this
case, calling memset on memory allocated with malloc should
segfault the same way when the system memory
[EMAIL PROTECTED] wrote:
memset should work with Xenomai heaps, I suspect your problem
is rather that the memory is not really allocated until you
memset it, which fails when no memory is available. In this
case, calling memset on memory allocated with malloc should
segfault the same way when
Wolfgang Grandegger wrote:
[EMAIL PROTECTED] wrote:
memset should work with Xenomai heaps, I suspect your problem is
rather that the memory is not really allocated until you memset it,
which fails when no memory is available. In this case, calling memset
on memory allocated with malloc should
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
[EMAIL PROTECTED] wrote:
memset should work with Xenomai heaps, I suspect your problem is
rather that the memory is not really allocated until you memset it,
which fails when no memory is available. In this case, calling memset
on memory allocated
The are some long delays (approx. 40 secs) around __alloc_pages.
Finally it crashes in memset. With the attached xenomai
patch, which
touches the reserved page once, memset works fine. Let's wait what
Philippe says. I remember that the touch was needed for
RTAI shared memory as
[EMAIL PROTECTED] wrote:
The are some long delays (approx. 40 secs) around __alloc_pages.
Finally it crashes in memset. With the attached xenomai
patch, which
touches the reserved page once, memset works fine. Let's wait what
Philippe says. I remember that the touch was
Maybe the task is in fact killed by the OOM killer ? It would
prove that this function is working correctly, since the
killed task is the one that allocates all the memory. Is
there no trace in the logs ?
Could not find a hint in the /var/log/messages from OOM killer. Nothing
that says
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to allocate as much memory as possible with the functions :
rt_heap_create and
rt_heap_alloc.
(see also Xenomai heap services in this mailing list; see source
attached)
When I try to use the allocated memory with memset,
[EMAIL PROTECTED] wrote:
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to allocate as much memory as possible with the functions :
rt_heap_create and
rt_heap_alloc.
(see also Xenomai heap services in this mailing list; see source
attached)
When
[EMAIL PROTECTED] wrote:
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to allocate as much memory as possible with the functions :
rt_heap_create and
rt_heap_alloc.
(see also Xenomai heap services in this mailing list; see source
attached)
When I try to use
Gilles Chanteperdrix wrote:
[EMAIL PROTECTED] wrote:
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to allocate as much memory as possible with the functions :
rt_heap_create and
rt_heap_alloc.
(see also Xenomai heap services in this mailing
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
[EMAIL PROTECTED] wrote:
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to allocate as much memory as possible with the functions :
rt_heap_create and
rt_heap_alloc.
(see also
13 matches
Mail list logo
