Eric H. Johnson wrote:
> The specific code generating the error is:
>
> /* now get shared memory block from OS and save its address */
> shmem_addr_array[shmem_id] = rtai_malloc(key, size);
> // the check for -1 here is because rtai_malloc (in at least
> // rtai 3.6.1, and probably others) has a bug where it
> // sometimes returns -1 on error
> if (shmem_addr_array[shmem_id] == NULL || shmem_addr_array[shmem_id] ==
> (void*)-1) {
> rtapi_mutex_give(&(rtapi_data->mutex));
> rtapi_print_msg(RTAPI_MSG_ERR,
> "RTAPI: ERROR: could not create shmem %d\n", n);
> return RTAPI_NOMEM;
> }
>
> The returned value from the call to rtai_malloc is consistently -1. I
> checked the values of the parameters to rtapi_shmem_new on both a working
> system and this system, and they are identical.
>
> The online documentation I found for rtai_malloc
> (https://www.rtai.org/documentation/magma/html/api/group__shm.html#ga68)
> defines rtai_malloc as (typos included <g>):
>
> <quote>
> #define rtai_malloc (name, size) _rt_shm_alloc(0, name, size, USE_VMALLOC,
> 0)
>
> Allocate a chunk of memory to be shared inter-intra kernel modules and Linux
> processes.
>
> rtai_malloc is used to allocate shared memory from user space.
>
> Parameters: name is an unsigned long identifier;
> size is the amount of required shared memory;
>
> rtai_malloc is a legacy helper macro, the real job is carried out by a call
> to rt_shm_alloc() with the same name, size and with vmalloc support. This
> function should not be used in newly developed applications. See
> rt_shm_alloc fro more details.
>
> Returns:
> a valid address on succes, 0 on failure.
> </quote>
>
> Among other things, this indicates to me a direct kernel call to a kernel
> with the rtai extensions. Thus it seems unlikely to have anything to do with
> the additional packages in a full ubuntu or xubuntu install.
>
> I don't know exactly what is going on when the emc install script
> (emc2-install.sh) is run. Is a rtai patched kernel just copied into /boot or
> does something get patched or otherwise modified locally to create the rtai
> kernel? Is it possible that something different happens at the install when
> only a minimal system is installed? Where is the -1 coming from which is not
> a defined result (comment refers to it as a bug)? Any ideas where to look
> next?
The -1 return value from rtai_malloc comes from _rt_shm_alloc
(rtai_shm.h:188). The mmap on line 202 returns MMAP_FAILED (-1) on
failure, and _rt_shm_alloc returns this value directly.
I asked the RTAI folks about this a couple of months ago, their response
was that the function returns the correct value and it's the docs that
are buggy.
<https://mail.rtai.org/pipermail/rtai/2008-November/020529.html>
--
Sebastian Kuzminsky
sky is black / stars show me the way
moon whispers how to keep my faith -- Korpiklaani
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers