[Bug 76701] New: Page Allocation failure during mount operation
Andrew Morton
akpm at linux-foundation.org
Thu May 22 00:06:34 PDT 2014
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 22 May 2014 06:35:38 +0000 bugzilla-daemon at bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=76701
>
> Bug ID: 76701
> Summary: Page Allocation failure during mount operation
> Product: Memory Management
> Version: 2.5
> Kernel Version: 2.6.37
> Hardware: ARM
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Page Allocator
> Assignee: akpm at linux-foundation.org
> Reporter: ravibhuva9955 at gmail.com
> Regression: No
>
> Created attachment 137081
> --> https://bugzilla.kernel.org/attachment.cgi?id=137081&action=edit
> Mount Error Logs
>
> Hello Friends,
>
> I am mounting configuration partition(NAND) during firmware upgrade and commit
> operations. And some times, I am getting error of mount failure and some of
> logs in syslog and dmesg(attached).
>
> So how to resolve this issue?
Jun 11 19:54:21 GJ-90012 user.warn kernel: mount: page allocation failure. order:5, mode:0x40d0
Jun 11 19:54:21 GJ-90012 user.warn kernel: Backtrace:
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c0052078>] (dump_backtrace+0x0/0x110) from [<c04dc338>] (dump_stack+0x18/0x1c)
Jun 11 19:54:21 GJ-90012 user.warn kernel: r6:00000001 r5:00000005 r4:000040d0 r3:60000013
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c04dc320>] (dump_stack+0x0/0x1c) from [<c00b0440>] (__alloc_pages_nodemask+0x4fc/0x560)
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c00aff44>] (__alloc_pages_nodemask+0x0/0x560) from [<c00b04bc>] (__get_free_pages+0x18/0x34)
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c00b04a4>] (__get_free_pages+0x0/0x34) from [<c00ce590>] (__kmalloc+0x3c/0xc0)
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c00ce554>] (__kmalloc+0x0/0xc0) from [<c0231d98>] (jffs2_scan_medium+0xdc/0x119c)
Jun 11 19:54:21 GJ-90012 user.warn kernel: r8:c0237228 r7:00020000 r6:ea6e1200 r5:00000000 r4:ea6e1c00
Jun 11 19:54:21 GJ-90012 user.warn kernel: r3:00000004
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c0231cbc>] (jffs2_scan_medium+0x0/0x119c) from [<c0234bf0>] (jffs2_do_mount_fs+0x180/0x59c)
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c0234a70>] (jffs2_do_mount_fs+0x0/0x59c) from [<c0236d80>] (jffs2_do_fill_super+0x154/0x238)
Jun 11 19:54:21 GJ-90012 user.warn kernel: r8:c0237228 r7:00020000 r6:ea6e1200 r5:00000000 r4:ea6e1c00
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c0236c2c>] (jffs2_do_fill_super+0x0/0x238) from [<c02372e4>] (jffs2_fill_super+0xbc/0xdc)
Jun 11 19:54:21 GJ-90012 user.warn kernel: r7:00000000 r6:00000001 r5:ea6e1c00 r4:ea6e1200
Jun 11 19:54:21 GJ-90012 user.warn kernel: [<c0237228>] (jffs2_fill_super+0x0/0xdc) from [<c0312944>] (mount_mtd_aux.clone.0+0x50/0xd4)
I'm not seeing mtd_kmalloc_up_to() in the backtrace, but that might be
a post-2.6.37 change.
Perhaps mtd_kmalloc_up_to() should be including __GFP_NOWARN in its
final kmalloc attemot, but that won't help you.
As for why the mount actually fails I cannot say - hopefully the fs
isn't dependent upon the success of an order-5 page allocation?
More information about the linux-mtd
mailing list