[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090413124228.be31e9f3.akpm@linux-foundation.org>
Date: Mon, 13 Apr 2009 12:42:28 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: reeve.yang@...il.com
Cc: bugzilla-daemon@...zilla.kernel.org, netdev@...r.kernel.org,
jeffrey.t.kirsher@...el.com, jesse.brandeburg@...el.com,
bruce.w.allan@...el.com, peter.p.waskiewicz.jr@...el.com,
john.ronciak@...el.com
Subject: Re: [Bugme-new] [Bug 13084] New: page allocation failure. order:0,
mode:0x20
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 13 Apr 2009 19:27:27 GMT
bugzilla-daemon@...zilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13084
>
> Summary: page allocation failure. order:0, mode:0x20
> Product: Memory Management
> Version: 2.5
> Kernel Version: 2.6.17.4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Page Allocator
> AssignedTo: akpm@...ux-foundation.org
> ReportedBy: reeve.yang@...il.com
> Regression: No
>
>
> Created an attachment (id=20964)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=20964)
> kernel config file.
>
> The system is Intel Xeon Quad core with 8G physical RAM. When it's under UPD
> loads, e.g., DNS queries, the box is stuck in terms it cannot be pinged or
> login. By checking syslog, I'm seeing following trace back from various
> dameon/processes. The network controller is E1000 82571 with NAPI enabled in
> kernel.
>
> page allocation failure. order:0, mode:0x20
This is very common. e1000 attempts to do large memory allocations
from within interrupt context and the page allocator cannot satisfy the
allocation and is not allowed to do the necessary work to make the
allocation attempt succeed. It's the same with all net drivers, but
e1000 is especially prone, apparently because of hardware suckiness.
However the networking stack should just drop the packet and the system
will recover.
You report is unclear. Yes, the machine wedges up under the UDP load.
But does it recover when the other machine stops spraying UDP packets
at this machine? It _should_ recover. If it does not, we have a bug
somewhere.
The usual workaround for these problems is to increase the value in
/proc/sys/vm/min_free_kbytes.
2.6.17 is fairly old. If we need to do additional work on this report
then we'll be asking you to test something more recent - ideally
2.6.29.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists