On Thu, Oct 13, 2005 at 06:32:03AM +0930, Berndt Josef Wulf wrote: > > > > (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) >
Try increasing shmmni and shmseg to 512 or 1024. > > (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 These are the SysV shared memory system calls. > > > (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... ;-) Sorry about that! I suspect that increasing shmmni and shmseg will fix your problem. > Anyone with FreeBSD seeing this problem too? > > cheerio Berndt Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
