On Wed, Oct 12, 2005 at 10:52:41AM +0930, Berndt Josef Wulf wrote:
> G'day,
>
> with CVS-current I'm getting the following message:
>
> barossa: {2} ./dial_tone.py
> gr_vmcircbuf_createfilemapping: createfilemapping is not available
> gr_vmcircbuf_sysv_shm: shmat (1): Too many open files
> gr_vmcircbuf_sysv_shm: shmat (1): Too many open files
> gr_vmcircbuf_sysv_shm: shmat (1): Too many open files
> gr_vmcircbuf_mmap_mkstemp: mmap or shm_open is not available
^^^^^^
Incorrect error message. Fixed in CVS. Should read:
gr_vmcircbuf_mmap_shm_open: mmap or shm_open is not available
> gr_vmcircbuf_sysconfig: unable to find a working factory!
>
> There was a lot of activity around the gr_vmcircbuf* code as of late that
> appears to have affected the current build on NetBSD.
>
> Any ideas?
I deleted the quite buggy (and oftentimes slow) gr_vmcircbuf_mmap_tmpfile class.
I didn't think anyone was using it. I'm reluctant to add it back as is,
given how hideous and hard to fix it was.
Here are some options:
(1) Re sysv_shm, increase the system limits using sysctl:
http://mail-index.netbsd.org/tech-kern/2002/07/07/0003.html
(2) gr_vmcircbuf_mmap_shm_open might work.
It requires mmap and shm_open. mmap has been around forever, and
shm_open is defined in POSIX 1003.1 (2001). Does NetBSD implement
both of these calls? If so, our configure tests need some tweaking.
Can you confirm or deny the availability of shm_open on NetBSD, and if
it exits, which library it's contained in?
(3) Fix gr_vmcircbuf_mmap_tmpfile so that it works reliably, and doesn't
unmap pieces of the address space that it didn't map in.
(4) Come up with some other way to get a single piece of physical
memory mapped into two adjacent virtual addresses. You may be able to
use mmap with MAP_ANON and/or /dev/zero and then remap it using some
kind of /proc/self/mem trick (didn't work on GNU/Linux).
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
