lkml.org 
[lkml]   [2000]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 3-order allocation failed
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/

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

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.074 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site