Hi,
> From: Pasi K?rkk?inen [mailto:[email protected]]
>
> On Thu, 26 Oct 2000, Rik van Riel wrote:
>
> > On Thu, 26 Oct 2000, Forever shall I be. wrote:
> > > On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi K?rkk?inen wrote:
> >
> > > > __alloc_pages: 2-order allocation failed.
> > > > __alloc_pages: 2-order allocation failed.
> > > > __alloc_pages: 5-order allocation failed.
> > > > __alloc_pages: 4-order allocation failed.
> > > > __alloc_pages: 3-order allocation failed.
> > > > __alloc_pages: 2-order allocation failed.
> > > > __alloc_pages: 5-order allocation failed.
> > > >
> > > > Any ideas?
> > >
> > > I'm getting __alloc_pages: 7-order allocation failed.
> > > all the time in 2.4.0-test9 on my "pIII (Katmai)".. kernel's
> > > compiled with 2.95.2 + bounds, without -fbounds-checking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Are there many places in the kernel that
do that (alloc 2^8 = 256 pages) .. after init?
Do you know where/what it is? Sound driver maybe?
> > It means something in the system is trying to allocate a
> > large continuous area of memory that isn't available...
> >
> > The printk is basically a debug output indicating that we
> > don't have the large physically contiguous area available
> > that's being requested.
> >
> > Basically everything bigger than order-1 (2 contiguous
> > pages) is unreliable at runtime. Orders 2 and 3 should
> > usually be available (if you only allocate very few of
> > them) and higher orders should not be relied upon.
> >
> > If somebody is seeing a lot of these messages, it means
> > that some driver in the system is asking unreasonable
> > things from the VM subsystem ;)
> >
> > (and buffer allocations are failing)
> >
>
> I got those order-x messages when I was running a script, that looked
> something like this:
>
> streamer -s 320x240 -o webcam.jpg
> sleep 5
>
> It worked fine for about 20 minutes, and after I started to get those
> messages and the camera didn't work anymore.
>
> Solution: I'm now using a program, that is "using the camera all the
> time" and it just saves the frames with 5 seconds delay.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Makes sense. Good, practical workaround solution.
I looked thru cpia_usb_open() and everything that it
calls or causes in your scenario, and the only
order-2 allocation that I see is in cpia_usb_open().
If order-1 allocs are much better than order-2 allocs,
like Rik said, then you could change
drivers/media/video/cpia_usb.c line 41 (in 2.4.0-test10)
to be: #define FRAMES_PER_DESC 8
instead of 10. That would make the kmalloc()'s in
cpia_usb_open() be order-1 instead of order-2.
All of the other kmalloc()s in the USB subsystem in this
scenarios are already small (less than 1 page).
Please let me/us know how this works if you try it.
> The script I was running previously used streamer, that
> initializes and
> opens the v4l-device everytime I run it.
>
> Is this bug in the usb-driver (usb-uhci), in the camera's driver
> (cpia_usb) or in the v4l?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Could there be a memory leak as well? But I expect that
it's simply that memory is just fragmented so that enough
contiguous pages aren't available, like Rik said.
~Randy
On Wed, Nov 01, 2000 at 01:42:17PM -0800, Dunlap, Randy wrote:
> > Is this bug in the usb-driver (usb-uhci), in the camera's driver
> > (cpia_usb) or in the v4l?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Could there be a memory leak as well? But I expect that
> it's simply that memory is just fragmented so that enough
> contiguous pages aren't available, like Rik said.
There is a memory leak, the memory kmalloc'ed in cpia_usb_open for
sbuf[*].data is never kfree'd (except when an error occurs during
initialisation). Adding some kfree's in cpia_usb_free_resources fixed
the problem in test7 or so, here's a patch against -test10.
--- drivers/media/video/cpia_usb.c.orig Wed Nov 1 14:14:37 2000
+++ drivers/media/video/cpia_usb.c Wed Nov 1 14:16:05 2000
@@ -432,10 +432,20 @@
ucpia->sbuf[1].urb = NULL;
}
+ if (ucpia->sbuf[1].data) {
+ kfree(ucpia->sbuf[1].data);
+ ucpia->sbuf[1].data = NULL;
+ }
+
if (ucpia->sbuf[0].urb) {
usb_unlink_urb(ucpia->sbuf[0].urb);
usb_free_urb(ucpia->sbuf[0].urb);
ucpia->sbuf[0].urb = NULL;
+ }
+
+ if (ucpia->sbuf[0].data) {
+ kfree(ucpia->sbuf[0].data);
+ ucpia->sbuf[0].data = NULL;
}
}
HTH.
Cheers,
aj
--
Anthony Towns <[email protected]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
On Thu, 2 Nov 2000, Anthony Towns wrote:
> On Wed, Nov 01, 2000 at 01:42:17PM -0800, Dunlap, Randy wrote:
> > > Is this bug in the usb-driver (usb-uhci), in the camera's driver
> > > (cpia_usb) or in the v4l?
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Could there be a memory leak as well? But I expect that
> > it's simply that memory is just fragmented so that enough
> > contiguous pages aren't available, like Rik said.
>
> There is a memory leak, the memory kmalloc'ed in cpia_usb_open
> for sbuf[*].data is never kfree'd
This way you'll be running out of order-2 free memory
segments /very/ quickly ... ;)
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
Hi Rik,
A simple test seems to show problems with page allocator.
a) take a 6G RAM machine
b) take a 70G harddisk
c) mke2fs on it
observe lots of "0-order allocation failures" while looking at
/proc/meminfo reveals that I still have 5.1G of free memory (presumably
some of it in NORMAL zone, not just all HIGH)... Isn't buddy allocator
clever enough to break up the multi-page chunks if we need single pages?
I don't know.
Regards,
Tigran