Re: [Discuss-gnuradio] GNU Radio CVS-current vmcirbuf problems

[Berndt Josef Wulf]

On Wed, 12 Oct 2005 11:48, Eric Blossom wrote:
> 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

shminfo:
        shmmax: 268435456       (max shared memory segment size)
        shmmin:       1 (min shared memory segment size)
        shmmni:     128 (max number of shared memory identifiers)
        shmseg:     128 (max shared memory segments per process)
        shmall:   65536 (max amount of shared memory in pages)

> (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?

mmap(2) as part of libc, but I couldn't find shm_open(?) in the hurry but the 
following:

shmat, shmdt (2) - map/unmap shared memory
shmctl (2) - shared memory control operations
shmget (2) - get shared memory segment


> (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).

Just when I thought things have settled ready for the next release... ;-)
Anyone with FreeBSD seeing this problem too?

cheerio Berndt

pgpveE_Dr3FbR.pgp
Description: PGP signature