I am setting up a ‘embedded’ gnuradio application, and have run across
the following diagnostic
message.
gri_fftw: Bad address
gr_vmcircbuf_createfilemapping: createfilemapping is not available
(null)/.gnuradio/prefs/gr_vmcircbuf_default_factory: No such file or
directory
I’ve noticed simular sorts of messages when I have my root disk ‘read
only’, etc.
But this one seems to cause the fft to stop processing.
What is this prefs item, and how do I set it up correctly in a embedded
environment, and use an http server to initiate the gnuradio application
(which
is probably why there is a ‘(null)’ in front of the directory for the
prefs, as
there may be no assigned directory for the http ‘user’ being used to
initiate
the application.)
Thanks
John C…
You left out a lot, like what operating system you are using. But
I’ll guess that gr_vmcircbuf_createfilemapping is trying to mmap a
file in tmp to get shared memory, and it needs to be writable.
Perhaps using mfs or tmpfs, or some other kind of memory filesystem
for /tmp is in order.
It may be that the diagnostics are not quite right. Try
ktrace/truss/etc.
–
Greg T. [email protected]
Greg T. schrieb:
You left out a lot, like what operating system you are using. But
I’ll guess that gr_vmcircbuf_createfilemapping is trying to mmap a
file in tmp to get shared memory, and it needs to be writable.
Perhaps using mfs or tmpfs, or some other kind of memory filesystem
for /tmp is in order.
I’m using Linux… and whatever ‘gr-vmcircbuf_createfilemapping’ is, is
buried deep in the gnuradio
sources.
In this case it looks like there’s a presumption about the ‘user’ and
having a directory associated with
that user, where ‘preferences’, etc. can be read/written, rather than
using say, /tmp or similar ‘well known’
writeable location.
I’ll have to do a find on the gnuradio sources to find the specific
reference, and then figure out
‘what to do’…
John C…
On Wed, Feb 28, 2007 at 11:30:52AM -0800, John C. wrote:
only’, etc.
the application.)
Try setting the HOME environment variable such that it points at a
writable directory.
Eric
John C. [email protected] writes:
In this case it looks like there’s a presumption about the ‘user’ and
having a directory associated with
that user, where ‘preferences’, etc. can be read/written, rather than
using say, /tmp or similar ‘well known’
writeable location.
So far people seem to run GNU Radio as users, so there are probably
hidden assumptions about the environment that need to be tracked down
and fixed. We were able to make it run as a daemon to receive 802.11
and inject the packets via a tap interface (on NetBSD). But, we
weren’t trying to do this on a ro filesystem.
truss is probably useful to find the failing system call.