E: comedi_set_buffer_size: Cannot allocate memory

[SA]

I've a puzzling problem: new install of kubuntu (Ubuntu 18.04.5 LTS / kernel 5.4.0-52-generic ).

Stock install of comedilib (libcomedi0/bionic,now 0.10.2-4build7 amd64).

Previously written code fails with "Cannot allocate memory".

comedi_test fails similarly:

comedi_test
I: Comedi version: 0.7.76
I: Comedilib version: unknown =)
I: driver name: ni_pcimio
I: device name: pci-6221

...

I: testing bufconfig...
buffer size 0
max buffer size 20971520
setting buffer size to 4096
buffer size set to 4096
buffer size now at 4096
setting buffer size past limit, 20975616
got EPERM, good
setting buffer size to max, 20971520
E: comedi_set_buffer_size: Cannot allocate memory

...

I'm not sure how to debug this - any suggestions gratefully received!

[SA]

I missed something out:

comedi_test -s0

I: testing cmd_fifo_depth_check...
read: Invalid argument
64, 0
read: Invalid argument
128, 0
read: Invalid argument
256, 0
read: Invalid argument
512, 0
read: Invalid argument
1024, 0
read: Invalid argument
2048, 0
read: Invalid argument
4096, 0
read: Invalid argument
8192, 0
read: Invalid argument
16384, 0
read: Invalid argument
32768, 0

I: testing cmd_start_inttrig...
E: comedi_command() returned -1, expecting 0
E: comedi_internal_trigger(): Resource temporarily unavailable
E: read: Invalid argument

[super...@gmail.com]

> > buffer size 0
> > max buffer size 20971520
> > setting buffer size to 4096
> > buffer size set to 4096
> > buffer size now at 4096
> > setting buffer size past limit, 20975616
> > got EPERM, good
> > setting buffer size to max, 20971520
> > E: comedi_set_buffer_size: Cannot allocate memory
> > ...
> >
> > I'm not sure how to debug this - any suggestions gratefully received!

Fixed:

comedi_config -v --read-buffer 1000

I think something got screwed up around the buffer_size leading to an
unfeasibly large maximum set. Setting something more realistic seems to have
fixed things.

[Ian Abbott]

If it was working before, this is likely to be a consequence to changes
made to Comedi in kernel version 5.3 related to buffer allocation. The
change affects buffer allocation for those devices that use DMA (direct
memory access) on the Comedi buffer. Previously, the buffer allocation
was split into lots of page-sized buffers, but now it is allocated as a
single, contiguous buffer. That means the allocation is more likely to
fail due to memory fragmentation, especially because it is allocated
from a special, "DMA-coherent" pool of kernel memory rather than the
normal pool of kernel memory.

This is a bit technical. The reason why the buffer allocation needed to
be changed from a bunch of pages to a single block was because the
method the Comedi code was using to support `mmap` on the buffer was
deemed to be invalid for DMA-coherent memory. I had to change the
`mmap` code to use a particular function for DMA memory, but that
function only supports `mmap` on a single contiguous block. If the
kernel's DMA API ever changes in the future to allow a DMA block to be
mapped to part of an mmap range, then I can change the code to use lots
of page-sized DMA buffers again. However, I don't think that is likely
in the near future.

--
-=( Ian Abbott <abb...@mev.co.uk> || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

[super...@gmail.com]

>
> This is a bit technical. The reason why the buffer allocation needed to
> be changed from a bunch of pages to a single block was because the
> method the Comedi code was using to support `mmap` on the buffer was
> deemed to be invalid for DMA-coherent memory. I had to change the
> `mmap` code to use a particular function for DMA memory, but that
> function only supports `mmap` on a single contiguous block. If the
> kernel's DMA API ever changes in the future to allow a DMA block to be
> mapped to part of an mmap range, then I can change the code to use lots
> of page-sized DMA buffers again. However, I don't think that is likely
> in the near future.

the technical explanation is fine - thanks - I realise kernel memory allocation
is complex.

I cannot tell how the problem originated. The physical installation has been
there for years running on an old kubuntu install dating back to before comedi
drivers were in the kernel I think. We've never seen this problem. This time
AFAIK the system was simply updated and the problem arose.

The buffer size (20Mb) it was asking for doesn't make much sense, I cannot see
that we'd have set this up during this install or any previous install and
20Mb seems excessively big. We were assuming this was some kind of default or
machine probed number so we've no idea why it was trying to get this.

Anyway setting the buffer size to something more likely that the kernel can
mange has fixed the problem.

[Frank Mori Hess]

On Thu, Jan 28, 2021 at 1:51 PM <super...@gmail.com> wrote:
>
> The buffer size (20Mb) it was asking for doesn't make much sense, I cannot see
> that we'd have set this up during this install or any previous install and
> 20Mb seems excessively big. We were assuming this was some kind of default or
> machine probed number so we've no idea why it was trying to get this.

The defaults for the buffer size and max buffer size are coming from
the comedi's kernel Kconfig. At some point in the past they used to
be hard coded and much smaller.

--
Frank

[super...@gmail.com]

> The defaults for the buffer size and max buffer size are coming from
> the comedi's kernel Kconfig. At some point in the past they used to
> be hard coded and much smaller.

Ok - but these aren't useful guaranteed values you can normally allocate? for
reference the machine exhibiting this problem is not resource starved...