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
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/
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
>
> 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.
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.
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
>
> 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 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.
"Pasi K?rkk?inen" wrote:
>
> 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.
>
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.