3-order allocation failed

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)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/ http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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.

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?

- Pasi Kärkkäinen

                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I added show_stack(0); to the mm/page_alloc.c :

        /* No luck.. */
        printk(KERN_ERR "__alloc_pages: %lu-order allocation failed.\n", order)
        show_stack(0);
        return NULL;

Then, when the first stack-dump came to kern.log, I gave it to ksymoops. The result can be seen on

http://edu.joroinen.fi/~pk/ksymoops-output.

Hope that helps someone. If not, I may do further tests.

- Pasi Kärkkäinen

                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alas:

Nov  1 12:48:34 mansion kernel: c3543e80 c01e5be0 00000002 00000000 00000007 c12277c8 00000007 00000007
Nov  1 12:48:34 mansion kernel:        00000000 c02200d4 c012bb44 c01288ad c12277c8 00000246 00000007 00000000
Nov  1 12:48:34 mansion kernel:        00000001 c0128ab9 c12277c8 00000007 c6529e60 00000000 c885ed60 c886e222
Nov  1 12:48:34 mansion kernel: Call Trace: [inet_check_attr+49792/72172] [<c012bb44>] [<c01288ad>] [<c0128ab9>] [<c885ed60>] [<c886e222>] [<c885ed60>]
Nov  1 12:48:39 mansion kernel:        [<c886911c>] [<c885e185>] [<c013866d>] [<c012f782>] [<c012e9b1>] [<c012e8ea>] [<c012ebdc>] [<c010a31f>] <3>__alloc_pages: 2-order

allocation failed.

...

Trace; c886911c <[cpia]cpia_open+88/160>
Trace; c885e185 <[videodev]video_open+79/94>
Trace; c013866d <permission+95/f4>
Trace; c012f782 <chrdev_open+3e/4c>
Trace; c012e9b1 <dentry_open+bd/148>
Trace; c012e8ea <filp_open+52/5c>
Trace; c012ebdc <sys_open+38/b4>
Trace; c010a31f <system_call+33/38>
Trace; c886911c <[cpia]cpia_open+88/160>

So your klogd tried to interpret the trace and screwed it up. Then ksymoops tried to interpret klogd's output and screwed it up.

Could you please change you init scripts so klogd' is started with the -x' option and then restart your logging daemons? There's a reasonable chance that if you do this your klogd will segfault and stop working when it sees the trace - I'm not sure if Debian have fixed this one.

Alternatively, if you still have that kernel,

cd /usr/src/linux
gdb vmlinux
x/10i 0xc01e5be0
x/10i 0xc02200d4
x/10i 0xc012bb44
x/10i 0xc01288ad
[etc]

That should (finally) tell us where the allocations are occurring. -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/