AFAIS, there are two parameters for shared memory: shmmax and shmall.
The first sets the maximum size for a single segment, the latter the
total available shared memory (in number of pages).
You could try to increase shmall as well.
Best,
Bastian
On 11/21/19 11:58 AM, Eamon Heaney wrote:
> Yeah,
Still gives the same error message, only with ">gr::vmcircbuf_mmap_tmpfile:
mmap (1): Cannot allocate memory" instead of "
>gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory."
On Thu, Nov 21, 2019 at 1:36 PM Philip Balister wrote:
> Look in
>
> ${HOME}/.gnuradio/prefs/vmcircbuf_def
Look in
${HOME}/.gnuradio/prefs/vmcircbuf_default_factory
and see what is there and maybe change to this:
gr::vmcircbuf_mmap_tmpfile_factory
Philip
On 11/21/19 4:59 AM, Eamon Heaney wrote:
> I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11,
> substituting a null sink for the US
Yeah, I tried changing the maximum shared memory, but that didn't work. I
mean, it didn't resolve the problem; I gave it 2147483648 but the error
persists. I tried adding a zero to that, but that's an "Invalid Argument."
On Thu, Nov 21, 2019 at 5:17 AM Ron Economos wrote:
> You must be running a
You must be running an older kernel that doesn't set kernel.shmmax to
some large value.
To check the current setting:
sysctl kernel.shmmax
To set it higher:
sudo -w kernel.shmmax=2147483648
Ron
On 11/21/19 01:59, Eamon Heaney wrote:
I'm running the sample wifi_tx.grc flowchart from gr-ieee8
I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11,
substituting a null sink for the USRP sink to test it.
When I try to run it, it fails with the following error message:
"
>set_min_output_buffer on block 7 to 207744
>set_min_output_buffer on block 9 to 2077440
>set_min_output_buffer
Hi everyone,
My question is around the following message:
"gr::buffer::allocate_buffer: warning: tried to allocate
728 items of size 90. Due to alignment requirements
2048 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 9, 2008, at 9:21 AM, Eric Blossom wrote:
You're probably running into a limit on the total number of shared
memory segments in the system (SHMMNI) or the max segs per process
(SHMMSEG). You can check the current values by:
$ cat /sys/proc/
On Fri, May 09, 2008 at 08:42:35AM -0700, Dan Halperin wrote:
> Hey,
>
> I know that the buffer allocation uses some memory mapping tricks to
> make it efficient; is there some shared resource that this process
> uses of which a computer should have a finite amount? I'm running a
> process w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
I know that the buffer allocation uses some memory mapping tricks to
make it efficient; is there some shared resource that this process
uses of which a computer should have a finite amount? I'm running a
process with, oh, say 500 buffers (
Hi,
Is there anything I can do to resolve warnings like this:
- - -
Creating block detail for vector_source_c(161)
Allocating new buffer for output 0
Creating block detail for single_pole_iir_filter_ff(158)
Allocating new buffer for output 0
gr_buffer::allocate_buffer: warning: tried to allocate
On Sat, Aug 20, 2005 at 03:10:05PM -0700, Ges wrote:
> Hi,
>
> I am a bit confused about where the buffer allocation
> is taking place for each block in a flowgraph.
>
> In flowgraph.py, the _assign_buffers() function,
> creates buffer and attaches to each block's detail.
_assign_buffers is whe
Hi,
I am a bit confused about where the buffer allocation
is taking place for each block in a flowgraph.
In flowgraph.py, the _assign_buffers() function,
creates buffer and attaches to each block's detail.
In single threaded scheduler's main_loop() fucntion,
vectors of DEFAULT_CAPACITY are bein
13 matches
Mail list logo
