From: Stephan Boettcher <boettcher@physik.uni-kiel.de>
To: Andreas Dilger <aedilger@gmail.com>
Cc: <linux-ext4@vger.kernel.org>
Subject: Re: 2.6.39.1: Intel I340-T4: irq/64-eth3-TxR: page allocation failure. order:1, mode:0x20
Date: Sat, 18 Jun 2011 19:39:55 +0200 [thread overview]
Message-ID: <s6nmxhft4wk.fsf@blaulicht.switch.brux> (raw)
In-Reply-To: <C9702C53-7906-46F5-B635-3ED698A394C2@gmail.com> (Andreas Dilger's message of "Sat, 18 Jun 2011 11:05:16 -0600")
Andreas Dilger <aedilger@gmail.com> writes:
> On 2011-06-18, at 10:19 AM, Mark Lord <kernel@teksavvy.com> wrote:
>> On 11-06-17 09:16 PM, Justin Piszcz wrote:
>>>
>>> Kernel 2.6.39.1, x86_64.
>>> Has anyone seen a page allocation failure on a NIC before?
>> ..
>>> [60295.925691] irq/64-eth3-TxR: page allocation failure. order:1, mode:0x20
>>> [60295.945328] Pid: 2299, comm: irq/64-eth3-TxR Not tainted 2.6.39.1 #1
>>> [60295.945329] Call Trace:
>>> [60295.945330] <IRQ> [<ffffffff810882f6>] ? __alloc_pages_nodemask+0x606/0x890
>>> [60295.945341] [<ffffffff810b1435>] ? cache_alloc_refill+0x2c5/0x530
>>> [60295.945343] [<ffffffff810b180b>] ? kmem_cache_alloc+0x7b/0xa0
>>> [60295.945347] [<ffffffff815031ac>] ? sk_prot_alloc.clone.35+0x3c/0x120
>>> [60295.945349] [<ffffffff81503320>] ? sk_clone+0x10/0x2b0
>>> [60295.945352] [<ffffffff815580bb>]
>>
>> Not on a NIC, but also with 2.6.39:
>>
>> [35850.612899] sd 4:0:0:0: [sdc] Attached SCSI disk
>> [35943.085264] mount: page allocation failure. order:5, mode:0xc0d0
>> [35943.085277] Pid: 14228, comm: mount Not tainted 2.6.39 #10
>> [35943.085284] Call Trace:
>> [35943.085306] [<ffffffff8106fa96>] ? __alloc_pages_nodemask+0x710/0x74d
>> [35943.085322] [<ffffffff8106fb5b>] ? __get_free_pages+0x12/0x50
>> [35943.085335] [<ffffffff810f9120>] ? ext4_fill_super+0xe4f/0x20ff
>> [35943.085347] [<ffffffff810f82d1>] ? ext4_remount+0x40e/0x40e
>
> There are a few places in the ext4 mount that are doing large
> allocations. In some places they fall back to vmalloc, so they should
> really be done with GFP_NOWARN.
>
> A few places don't yet fall back to vmalloc(), which is a problem
> with fragmented memory or very large filesystems. We were trying to
> test a 192TB ext4 filesystem, but were unable to mount it without
> patching the kernel.
:-O ... my puny 20TB ext4 filesystem did not do something like
this, yet.
> Cheers, Andreas--
--
Stephan
next prev parent reply other threads:[~2011-06-18 18:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-18 1:16 2.6.39.1: Intel I340-T4: irq/64-eth3-TxR: page allocation failure. order:1, mode:0x20 Justin Piszcz
2011-06-18 16:19 ` Mark Lord
2011-06-18 16:19 ` Mark Lord
2011-06-18 16:21 ` Mark Lord
2011-06-18 17:05 ` Andreas Dilger
2011-06-18 17:39 ` Stephan Boettcher [this message]
2011-06-18 19:44 ` Andreas Dilger
2011-06-19 11:28 ` Stephan Boettcher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s6nmxhft4wk.fsf@blaulicht.switch.brux \
--to=boettcher@physik.uni-kiel.de \
--cc=aedilger@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.