Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

modprobe: page allocation failure #2

Closed
John2k12 opened this issue Jul 22, 2012 · 2 comments
Closed

modprobe: page allocation failure #2

John2k12 opened this issue Jul 22, 2012 · 2 comments

Comments

@John2k12
Copy link

After kernel compilation i get his message while booting up:

EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
vmalloc: allocation failure: 0 bytes
modprobe: page allocation failure: order:0, mode:0xd0
Backtrace:
Function entered at [] from []
r6:c032f1c4 r5:000000d0 r4:00000001 r3:c03a71c8
Function entered at [] from []
Function entered at [] from []
r3:00000000 r2:c032f1c4
r8:000000d0 r7:ffffffff r6:c00499e8 r5:000003e8 r4:00000000
Function entered at [] from []
r8:ce903028 r7:c0307e78 r6:00000000 r5:000003e8 r4:000000d0
Function entered at [] from []
r4:bf081000
Function entered at [] from []
r6:00000019 r5:000003e8 r4:bf081000 r3:00000000
Function entered at [] from []
Mem-info:
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 38
active_anon:438 inactive_anon:30 isolated_anon:0
active_file:1295 inactive_file:1934 isolated_file:0
unevictable:405 dirty:0 writeback:0 unstable:0
free:50315 slab_reclaimable:305 slab_unreclaimable:635
mapped:472 shmem:32 pagetables:78 bounce:0
Normal free:201260kB min:1908kB low:2384kB high:2860kB active_anon:1752kB inactive_anon:120kB active_file:5180kB inactive_file:7736kB unevictable:1620kB isolated(anon):0kB isolated(file):0kB present:227584kB mlocked:1620kB dirty:0kB writeback:0kB mapped:1888kB shmem:128kB slab_reclaimable:1220kB slab_unreclaimable:2540kB kernel_stack:360kB pagetables:312kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 177_4kB 169_8kB 106_16kB 52_32kB 22_64kB 3_128kB 4_256kB 1_512kB 2_1024kB 1_2048kB 46*4096kB = 201260kB
3595 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
57344 pages of RAM
50449 free pages
1519 reserved pages
940 slab pages
3254 pages shared
0 pages swap cached

snd_bcm2835_alsa_probe c03a6218 ############### PROBING FOR bcm2835 ALSA device (0):(1)

RPi seems to work normally, but it would be nice to know what causes this failure.

Thx and best regards,

John
@John2k12
Copy link
Author

I've enabled kobject debugging, maybe its helpfull:

kobject: 'snd_page_alloc' (bf06e98c): kobject_uevent_env
kobject: 'snd_page_alloc' (bf06e98c): fill_kobj_path: path = '/module/snd_page_alloc'
kobject: 'snd_pcm' (bf07dd20): kobject_add_internal: parent: 'module', set: 'module'
kobject: 'holders' (cc8a38e0): kobject_add_internal: parent: 'snd_pcm', set: ''
kobject: 'snd_pcm' (bf07dd20): kobject_uevent_env
kobject: 'snd_pcm' (bf07dd20): fill_kobj_path: path = '/module/snd_pcm'
vmalloc: allocation failure: 0 bytes
modprobe: page allocation failure: order:0, mode:0xd0
Backtrace:
Function entered at [] from []
r6:c032f224 r5:000000d0 r4:00000001 r3:c03a71c8
Function entered at [] from []
Function entered at [] from []
r3:00000000 r2:c032f224
r8:000000d0 r7:ffffffff r6:c00499e8 r5:000003e8 r4:00000000
Function entered at [] from []
r8:ce903028 r7:c0307e78 r6:00000000 r5:000003e8 r4:000000d0
Function entered at [] from []
r4:bf081000
Function entered at [] from []
r6:00000019 r5:000003e8 r4:bf081000 r3:00000000
Function entered at [] from []
Mem-info:
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 30
active_anon:430 inactive_anon:30 isolated_anon:0
active_file:1046 inactive_file:2344 isolated_file:0
unevictable:405 dirty:0 writeback:0 unstable:0
free:50197 slab_reclaimable:302 slab_unreclaimable:610
mapped:473 shmem:32 pagetables:79 bounce:0
Normal free:200788kB min:1908kB low:2384kB high:2860kB active_anon:1720kB inactive_anon:120kB active_file:4184kB inactive_file:9376kB unevictable:1620kB isolated(anon):0kB isolated(file):0kB present:227584kB mlocked:1620kB dirty:0kB writeback:0kB mapped:1892kB shmem:128kB slab_reclaimable:1208kB slab_unreclaimable:2440kB kernel_stack:360kB pagetables:316kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 161_4kB 164_8kB 99_16kB 40_32kB 14_64kB 6_128kB 1_256kB 3_512kB 2_1024kB 1_2048kB 46*4096kB = 200788kB
3756 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
57344 pages of RAM
50323 free pages
1519 reserved pages
912 slab pages
3424 pages shared
0 pages swap cached
kobject: 'snd_bcm2835' (bf084b04): kobject_add_internal: parent: 'module', set: 'module'
kobject: 'holders' (cd97f9a0): kobject_add_internal: parent: 'snd_bcm2835', set: ''
kobject: 'snd_bcm2835' (bf084b04): kobject_uevent_env
kobject: 'snd_bcm2835' (bf084b04): fill_kobj_path: path = '/module/snd_bcm2835'
kobject: 'bcm2835_AUD0' (cc933960): kobject_add_internal: parent: 'drivers', set: 'drivers'
snd_bcm2835_alsa_probe c03a6218

Best,

John

@bootc
Copy link
Owner

bootc commented Jul 28, 2012

Sadly your backtraces are useless as they don't include any function names, but your kobject debugging seems to point at the snd_bcm2835 driver. Do you have this compiled-in or as a module? This isn't a driver I've looked at before so I don't really have any idea about what might cause this.

@bootc bootc closed this as completed Aug 12, 2012
bootc pushed a commit that referenced this issue Aug 25, 2012
@jtlayton @bwhacks
cifs: when CONFIG_HIGHMEM is set, serialize the read/write kmaps
bb761c9 
commit 3cf003c upstream.

Jian found that when he ran fsx on a 32 bit arch with a large wsize the
process and one of the bdi writeback kthreads would sometimes deadlock
with a stack trace like this:

crash> bt
PID: 2789   TASK: f02edaa0  CPU: 3   COMMAND: "fsx"
 #0 [eed63cbc] schedule at c083c5b3
 #1 [eed63d80] kmap_high at c0500ec8
 #2 [eed63db] cifs_async_writev at f7fabcd7 [cifs]
 #3 [eed63df0] cifs_writepages at f7fb7f5c [cifs]
 #4 [eed63e50] do_writepages at c04f3e32
 #5 [eed63e54] __filemap_fdatawrite_range at c04e152a
 #6 [eed63ea4] filemap_fdatawrite at c04e1b3e
 #7 [eed63eb4] cifs_file_aio_write at f7fa111a [cifs]
 torvalds#8 [eed63ecc] do_sync_write at c052d202
 torvalds#9 [eed63f74] vfs_write at c052d4ee
torvalds#10 [eed63f94] sys_write at c052df4c
torvalds#11 [eed63fb0] ia32_sysenter_target at c0409a98
    EAX: 00000004  EBX: 00000003  ECX: abd73b73  EDX: 012a65c6
    DS:  007b      ESI: 012a65c6  ES:  007b      EDI: 00000000
    SS:  007b      ESP: bf8db178  EBP: bf8db1f8  GS:  0033
    CS:  0073      EIP: 40000424  ERR: 00000004  EFLAGS: 00000246

Each task would kmap part of its address array before getting stuck, but
not enough to actually issue the write.

This patch fixes this by serializing the marshal_iov operations for
async reads and writes. The idea here is to ensure that cifs
aggressively tries to populate a request before attempting to fulfill
another one. As soon as all of the pages are kmapped for a request, then
we can unlock and allow another one to proceed.

There's no need to do this serialization on non-CONFIG_HIGHMEM arches
however, so optimize all of this out when CONFIG_HIGHMEM isn't set.

Reported-by: Jian Li <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
bootc pushed a commit that referenced this issue Aug 25, 2012
@jtlayton @bwhacks
nfs: skip commit in releasepage if we're freeing memory for fs-relate…
1c88c58 
…d reasons

commit 5cf02d0 upstream.

We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:

    PID: 2507   TASK: ffff88103691ab40  CPU: 14  COMMAND: "rpciod/14"
     #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9
     #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs]
     #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f
     #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8
     #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs]
     #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs]
     #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670
     #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271
     torvalds#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638
     torvalds#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f
    torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e
    torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f
    torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad
    torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942
    torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a
    torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9
    torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b
    torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808
    torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c
    torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6
    torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7
    torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc]
    torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc]
    torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0
    torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96
    torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca

rpciod is trying to allocate memory for a new socket to talk to the
server. The VM ends up calling ->releasepage to get more memory, and it
tries to do a blocking commit. That commit can't succeed however without
a connected socket, so we deadlock.

Fix this by setting PF_FSTRANS on the workqueue task prior to doing the
socket allocation, and having nfs_release_page check for that flag when
deciding whether to do a commit call. Also, set PF_FSTRANS
unconditionally in rpc_async_schedule since that function can also do
allocations sometimes.

Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bootc @John2k12