I’m seeing this issue on my omap3 install with the dialtone flowgraph:
python /usr/share/gnuradio/examples/audio/dial_tone.py
gr_vmcircbuf_createfilemapping: createfilemapping is not available
gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument
l# python /usr/share/gnuradio/examples/audio/dial_tone.py
In both cases I can hear the dial tone fine. I’m curious why I get the
shmat error the first time only. It looks like gnuradio falls back to
another method of creating the shared segment. I’d like to resolve the
shmat issue though, because I am also trying to run the kalibrate
program and have the same shmat issue there, but it does not have a fall
back method.
Thanks,
Philip
On Tue, Oct 19, 2010 at 08:34:40PM -0400, Philip B. wrote:
I’m seeing this issue on my omap3 install with the dialtone flowgraph:
python /usr/share/gnuradio/examples/audio/dial_tone.py
gr_vmcircbuf_createfilemapping: createfilemapping is not available
gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument
l# python /usr/share/gnuradio/examples/audio/dial_tone.py
From $ man shmat
EINVAL Invalid shmid value, unaligned (i.e., not page-aligned and
SHM_RND was not speci-
fied) or invalid shmaddr value, or can’t attach segment at
shmaddr, or SHM_REMAP was
specified and shmaddr was NULL.
In both cases I can hear the dial tone fine. I’m curious why I get
the shmat error the first time only.
You should see it only once ever, if the program can write to
~/.gnuradio/prefs. Generally this gets written during “make check”.
Does “make check” work?
Why are you running as root?
It looks like gnuradio falls
back to another method of creating the shared segment.
Yes it does.
I’d like to resolve the shmat issue though,
Set a breakpoint with gdb, or add printfs.
because I am also trying to run the kalibrate program and have the
same shmat issue there, but it does not have a fall back method.
Eric
On 10/19/2010 10:51 PM, Eric B. wrote:
l# python /usr/share/gnuradio/examples/audio/dial_tone.py
From $ man shmat
EINVAL Invalid shmid value, unaligned (i.e., not page-aligned and SHM_RND
was not speci-
fied) or invalid shmaddr value, or can’t attach segment at shmaddr, or
SHM_REMAP was
specified and shmaddr was NULL.
I hate system calls that have one error code for several errors.
In both cases I can hear the dial tone fine. I’m curious why I get
the shmat error the first time only.
You should see it only once ever, if the program can write to
~/.gnuradio/prefs. Generally this gets written during “make check”.
Does “make check” work?
Insert whining about make check for the cross compiled case 
Why are you running as root?
I am lazy
It looks like gnuradio falls
back to another method of creating the shared segment.
Yes it does.
I’d like to resolve the shmat issue though,
Set a breakpoint with gdb, or add printfs.
OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 *
PAGE_SIZE. Need to puzzle through this a little more. This is the
failing check in the kernel.
Philip
On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip B. wrote:
Insert whining about make check for the cross compiled case
Why are you running as root?
I am lazy
And foolish
PAGE_SIZE. Need to puzzle through this a little more. This is the
failing check in the kernel.
OK. What’s PAGE_SIZE on arm?
I wonder how we can determine the actual value of SHMLBA at runtime?
We currently use the result of gr_pagesize() as the required alignment
value.
Eric
On 10/20/2010 01:49 PM, Eric B. wrote:
On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip B. wrote:
On 10/19/2010 10:51 PM, Eric B. wrote:
OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 *
PAGE_SIZE. Need to puzzle through this a little more. This is the
failing check in the kernel.
OK. What’s PAGE_SIZE on arm?
PAGE_SIZE is still 4096, there is an additional restriction on the
address passed to shmat().
I wonder how we can determine the actual value of SHMLBA at runtime?
We currently use the result of gr_pagesize() as the required alignment value.
It looks to me like the there are several shm sections created, with
varying access rights. Then shmat is used to reserve a chunk of memory.
Then the sections created first are attached to with addresses based on
the result of the shmat used to get the address space.
The weird thing on arm, the shmat returns a page aligned section, but if
you pass that address back to shmat it fails, because that address needs
to be aligned to SHMLBA (found in arch/arm|x86/include/asm/shmparam.h.
What does it mean?
Well gnuradio falls back to a mmap approach to get the circular buffer.
It is a bigger problem for kalibrate, which just fails.
I’m not sure who is to blame Is there another way to get reserve the
memory on you process to use when you attach the shared memory segments?
Philip
Quoting Philip B. ([email protected]):
On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip B. wrote:
On 10/19/2010 10:51 PM, Eric B. wrote:
OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 *
PAGE_SIZE. Need to puzzle through this a little more. This is the
failing check in the kernel.
OK. What’s PAGE_SIZE on arm?
PAGE_SIZE is still 4096, there is an additional restriction on the
address passed to shmat().
Is the additional restriction ‘4 * PAGE_SIZE’? If so, look in the
circular_buffer.cc for kalibrate and change the line that reads:
m_pagesize = getpagesize();
to
m_pagesize = 4 * getpagesize();
It may be that easy. The rest of the logic should work.
Alternatively, you can force the use of Posix shared memory and see if
that works for kalibrate on your platform. (The easiest thing to do
would be to look for D_HOST_OSX and make sure those #ifdef’s are the
ones that gets compiled.)
Email me with your results and I’ll add some code to make arm work in
the next version of kal.
On 10/25/2010 07:36 PM, Joshua L. wrote:
address passed to shmat().
It may be that easy. The rest of the logic should work.
Basically, yes. Unfortunately, this didn’t work. I’ll double check when
I get back from ELCE. It seems like the shm code returns an address that
is not valid for using as an address you pass to shmat 
Alternatively, you can force the use of Posix shared memory and see if
that works for kalibrate on your platform. (The easiest thing to do
would be to look for D_HOST_OSX and make sure those #ifdef’s are the
ones that gets compiled.)
I’ll check this when I get home.
Email me with your results and I’ll add some code to make arm work in
the next version of kal.
Thanks! Could we use the mmap code from gnuradio? That is what ends up
being used there I think. I skimmed the shm code while working on this
problem, and it looks like it used mmap internally
Philip
On Wed, Oct 20, 2010 at 02:30:12PM -0400, Philip B. wrote:
address passed to shmat().
I’m not sure who is to blame Is there another way to get reserve
the memory on you process to use when you attach the shared memory
segments?
Philip,
If you run “make check”, it will probe for an implementation that
works. Under *unix variants, there are three different
implementations that are tried:
gr_vmcircbuf_sysv_shm.cc
gr_vmcircbuf_mmap_shm_open.cc
gr_vmcircbuf_mmap_tmpfile.cc
Under windows, it uses
gr_vmcircbuf_createfilemapping.cc
Since you’re probably not going to get make check working in our
lifetimes, try this:
$ echo -n “gr_vmcircbuf_mmap_shm_open_factory” >
~/.gnuradio/prefs/gr_vmcircbuf_default_factory
Or this:
$ echo -n “gr_vmcircbuf_mmap_tmpfile_factory” >
~/.gnuradio/prefs/gr_vmcircbuf_default_factory
Even if they both work, they may have different runtime performance.
YMMV…
Eric
Quoting Philip B. ([email protected]):
[…]
Thanks! Could we use the mmap code from gnuradio? That is what ends up
being used there I think. I skimmed the shm code while working on this
problem, and it looks like it used mmap internally
mmap is the Posix shared memory method.