All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Antoniac <theSeinfeld@users.sourceforge.net>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Arjan van de Ven <arjan@infradead.org>,
	Peter Antoniac <theSeinfeld@users.sourceforge.net>,
	linux-kernel@vger.kernel.org,
	libdc1394-devel@lists.sourceforge.net,
	linux1394-devel@lists.sourceforge.net
Subject: Re: allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem
Date: Mon, 15 Jan 2007 13:14:11 +0900	[thread overview]
Message-ID: <200701151314.11922.theSeinfeld@users.sf.net> (raw)
In-Reply-To: <tkrat.832df3763908c060@s5r6.in-berlin.de>

On Monday 15 January 2007 05:31, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
>
> I suppose "grep VmallocChunk /proc/meminfo" shows what is available?

This is more the answer that I expect. But is there a way, function or 
constant from libdc that can give you the answer, or you have to get it from 
the /proc/meminfo? Now, if you can only get it from the /proc/meminfo, is 
this info always there? As far as I remember, you can compile kernels without 
the /proc/meminfo...

And yes, probably we would have to get rid of this issue and look for an 
alternative way. Still, from a technical point of view, I am really curious 
if this information on the size of VmallocChunk is available to the developer 
in other forms...

Thank you all!

Cheers,
Peter

> > it really sounds like vmalloc space isn't the right solution for your
> > problem whatever it is (context is lost in the quoted mail)...
> > can you restate the problem to see if there's a better solution
> > possible?
>
> Thanks. Below is Peter's message to linux1394-devel. The previous
> discussion went over libdc1394-devel which I don't receive. Obviously he
> wants a really large buffer for reception of an isochronous stream. I
> guess his reason is highly application specific...
>
> | Hi all,
> |
> | I've been trying to get a resolution to the problem with vmalloc error
> | (the <<allocation failed: out of vmalloc space - use vmalloc=<size> to
> | increase size.>> kernel error message thing). The plan how to resolve the
> | issue is simple; get the buffer size that we try to allocate
> | (vmmap.nb_buffers * vmmap.buf_size) and compare it to the
> | VMALLOC_RESERVED. If too big, error with explanation how to fix it. If
> | small, other error (usual out of mem). Problem is: how to get the
> | VMALLOC_RESERVED value for the kernel that is running? I couldn't find
> | any standard way to do that (something to apply to GNU Linux and the
> | like). All the things I could get were the default value being 128MiB :)
> | and that is it. Now, I could just put 128, but what if somebody changes
> | that, or in some new distro suddenly decides to make it different? Even
> | worse, what if it is an old kernel with 64 setting?
> |
> | Currently, in the SVN version, Damien was kind to change so that a
> | message gets printed with a full explanation of how to treat it. Still,
> | this is a compromise solution and not the elegant one that I was looking
> | for. I believe and hope that maybe somebody had this issue before and
> | could help with some suggestions...
> |
> | So, my question is: anybody knows the way to get to the kernel value like
> | VMALLOC_RESERVED or something around this area (a function like
> | getpagesize or sysconf)? It will do a great deal to solve the problematic
> | error treatment in the library...
> |
> | Thank you.
> |
> | For your reference, this is in response to this line of thinking or the
> | libdc1394-devel thread:
> | [...]
> |
> | > > When I set NUM_BUFFERS (number of DMA buffers) to a value greater
> | > > than 5 the program dies like this:
> | > >
> | > > (dc1394_capture.c) VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed!
> | > > Libdc1394 error (dc1394_capture.c:dc1394_capture_setup_dma:382):
> | > > Capture is not set : Could not setup DMA capture
> |
> | [...]
> |
> | > > [17723533.496000] video1394_0: Iso receive DMA: 8 buffers of size
> | > > 6627328 allocated for a frame size 6624000, each with 1619 prgs
> | > > [17723533.516000] video1394_0: iso context 0 listen on channel 1
> | > > [17723533.712000] ieee1394: Node [1-01:1023] wants to release
> | > > broadcast channel 31.  Ignoring.
> | > > [17723534.448000] video1394_1: mask: 0000000000000004 usage:
> | > > 0000000000000000
> | > > [17723534.448000]
> | > > [17723534.508000] video1394_1: Iso receive DMA: 8 buffers of size
> | > > 6627328 allocated for a frame size 6624000, each with 1619 prgs
> | > > [17723534.532000] video1394_1: iso context 0 listen on channel 2
> | > > [17723534.728000] ieee1394: Node [2-01:1023] wants to release
> | > > broadcast channel 31.  Ignoring.
> | > > [17723535.464000] video1394_2: mask: 0000000000000008 usage:
> | > > 0000000000000000
> | > > [17723535.464000]
> | > > [17723535.464000] printk: 11 messages suppressed.
> | > > [17723535.464000] allocation failed: out of vmalloc space - use
> | > > vmalloc=<size> to increase size.
> | > > [17723535.464000] dma_region_alloc: vmalloc_32() failed
> | > > [17723535.464000] video1394_2: Failed to allocate dma buffer
> | > > [17723535.464000] video1394_2: Couldn't allocate ir context
> | > > [17723535.668000] video1394_0: On release: Iso receive context 0 stop
> | > > listening on channel 1
> | > > [17723535.676000] video1394_1: On release: Iso receive context 0 stop
> | > > listening on channel 2
> |
> | [...]
> |
> | > ------------------------------
> | >
> | > Message: 2
> | > Date: Fri, 05 Jan 2007 17:30:39 +0100
> | > From: Martin Peris <xxxxxxxxxxxxxxxxxxx>
> | > Subject: Re: [libdc1394-devel] [SPAM RBL] Re:
> | >         VIDEO1394_IOC_LISTEN_CHANNEL    ioctl failed! and Bad images
> | > To: Damien Douxchamps <xxxxxxxxxxxxxxxxxxxxx>
> | > Cc: libdc1394-devel <xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> |
> | [...]
> |
> | > I think I have some answers...
> | >
> | > I've been investigating a bit, and the  problem with the limit in the
> | > size of the allocated DMA buffer  is not so obscure.
> | >
> | > vmalloc_32() allocate virtually contiguous memory (32bit addressable),
> | > the default maximum amount of memory reserved for this depends on each
> | > kernel compilation, and in my case it was set to 128Mbytes that's why I
> | > had an error if tried to allocate too many buffers.
> | >
> | >  but at boot time you can specify how much virtually contiguous memory
> | > you want with the parameter vmalloc, so if you want about 512Mbytes of
> | > memory for vmalloc you should add the parameter vmalloc=536870912 to
> | > the line that defines the kernel parameters. (If you use grub there
> | > should be a line like this on /boot/grub/menu.lst)
> | >
> | > kernel          /boot/vmlinuz-2.6.15-27-686 root=/dev/sda2
> | > vmalloc=536870912 ro quiet splash
> | >
> | >
> | > That killed my problem with:
> | >
> | > dc1394_capture.c) VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed!
> | > Libdc1394 error (dc1394_capture.c:dc1394_capture_setup_dma:382):
> | > Capture is not set : Could not setup DMA capture
> |
> | [...]

  parent reply	other threads:[~2007-01-15  4:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.59.1168027378.1221.libdc1394-devel@lists.sourceforge.net>
     [not found] ` <200701100023.39964.theSeinfeld@users.sf.net>
2007-01-14 19:19   ` allocation failed: out of vmalloc space error treating and VIDEO1394 IOC LISTEN CHANNEL ioctl failed problem Stefan Richter
2007-01-14 19:28     ` Arjan van de Ven
2007-01-14 20:31       ` Stefan Richter
2007-01-14 20:48         ` Arjan van de Ven
2007-01-15  4:14         ` Peter Antoniac [this message]
2007-01-15  6:01           ` Peter Antoniac
2007-01-15 18:02       ` Bill Davidsen
2007-01-15 18:20         ` Arjan van de Ven
2007-01-15 19:54           ` David Moore
2007-01-15 21:06             ` Kristian Høgsberg
2007-01-15 21:24               ` Arjan van de Ven
2007-01-15 21:43                 ` Kristian Høgsberg
2007-01-16  2:40                   ` Peter Antoniac
2007-01-16  5:21                   ` David Moore
2007-01-16 17:58                     ` Arjan van de Ven
2007-01-16  8:16             ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200701151314.11922.theSeinfeld@users.sf.net \
    --to=theseinfeld@users.sourceforge.net \
    --cc=arjan@infradead.org \
    --cc=libdc1394-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.