search for: __alloc_pages

...p CRON[30145]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons ) Jan 12 15:12:27 palmtrace-nuvoip tftpd[7279]: Serving ata000d28383ca9 to 10.9.8.49:6616 Jan 12 15:12:27 palmtrace-nuvoip tftpd[21012]: Serving atadefault.cfg to 10.9.8.49:6617 Jan 12 15:13:43 palmtrace-nuvoip __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) Jan 12 15:13:43 palmtrace-nuvoip VM: killing process mpg123 Jan 12 15:13:48 palmtrace-nuvoip __alloc_pages: 0-order allocation failed (gfp=0x1f0/0) Jan 12 15:13:48 palmtrace-nuvoip __alloc_pages: 0-order allocation failed (gfp=0x1f0/0) Jan 12 15:14:17 pa...

...e+0x13a/0x300 Jun 10 10:28:59 shawarma kernel: [shrink_zone+170/288] shrink_zone+0xaa/0x120 Jun 10 10:28:59 shawarma kernel: [shrink_caches+92/128] shrink_caches+0x5c/0x80 Jun 10 10:28:59 shawarma kernel: [try_to_free_pages+148/384] try_to_free_pages+0x94/0x180 Jun 10 10:28:59 shawarma kernel: [__alloc_pages+422/768] __alloc_pages+0x1a6/0x300 Jun 10 10:28:59 shawarma kernel: [do_page_cache_readahead+231/288] do_page_cache_readahead+0xe7/0x120 Jun 10 10:28:59 shawarma kernel: [filemap_nopage+705/800] filemap_nopage+0x2c1/0x320 Jun 10 10:28:59 shawarma kernel: [do_no_page+144/672] do_no_page+0x90/0x2a...

...0 0 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 548kB Normal: empty HighMem: empty Swap cache: add 120470, delete 120465, find 45260/94674, race 0+2 printk: 51 messages suppressed. init: page allocation failure. order:0, mode:0x20 [<c01417a3>] __alloc_pages+0x2b3/0x430 [<c916d528>] br_nf_forward_finish+0xb8/0x140 [bridge] [<c0144611>] kmem_getpages+0x31/0xa0 [<c9167d70>] br_forward_finish+0x0/0x70 [bridge] [<c014537e>] cache_grow+0x9e/0x190 [<c01455bd>] cache_alloc_refill+0x14d/0x220 [<c9167d70>] br_forward_fi...

...server kernel: 0 pages writeback Dec 8 12:19:28 server kernel: 5214 pages mapped Dec 8 12:19:28 server kernel: 17017 pages slab Dec 8 12:19:28 server kernel: 115 pages pagetables Dec 8 12:19:28 server kernel: swapper: page allocation failure. order:0, mode:0x20 Dec 8 12:19:28 server kernel: [__alloc_pages+593/611] __alloc_pages+0x251/0x263 Dec 8 12:19:28 server kernel: [kmem_getpages+57/136] kmem_getpages+0x39/0x88 Dec 8 12:19:28 server kernel: [cache_grow+188/372] cache_grow+0xbc/0x174 Dec 8 12:19:28 server kernel: [cache_alloc_refill+366/439] cache_alloc_refill+0x16e/0x1b7 Dec 8 12:19:28 se...

The system stopped responding to ssh but still responded to ping. The logs showed this error: (its long) Feb 4 00:08:08 server1 kernel: gdmgreeter: page allocation failure. order:0, mode:0x50 Feb 4 00:08:08 server1 kernel: [<c014f863>] __alloc_pages+0x28b/0x29d Feb 4 00:08:08 server1 kernel: [<c014b70f>] find_or_create_page+0x39/0x72 Feb 4 00:08:08 server1 kernel: [<c016eda7>] grow_dev_page+0x2a/0x1eb Feb 4 00:08:08 server1 kernel: [<c016f096>] __getblk_slow+0x12e/0x159 Feb 4 00:08:08 server1 kernel: [<c016f40e>...

...d and 4 idling domU''s) Aug 15 14:40:27 xen5etch kernel: printk: 36 messages suppressed. Aug 15 14:40:30 xen5etch kernel: oom-killer: gfp_mask=0x280d2, order=0 Aug 15 14:40:30 xen5etch kernel: [<c013f243>] out_of_memory+0x25/0x13a Aug 15 14:40:30 xen5etch kernel: [<c0140721>] __alloc_pages+0x1f5/0x275 Aug 15 14:40:30 xen5etch kernel: [<c0147fba>] __handle_mm_fault+0x2fc/0xfa3 Aug 15 14:40:30 xen5etch kernel: [<c01405fb>] __alloc_pages+0xcf/0x275 Aug 15 14:40:30 xen5etch kernel: [<c0288eec>] schedule+0x628/0x6e0 Aug 15 14:40:30 xen5etch kernel: [<c0146d2a>]...

...00000000 c0630a84 00000000 00000008 00000000 c1587418 c0630200 00000018 0000001f Call Trace: [<c015e2ea>] move_freepages_block+0x6a/0x80 [<c015e5d9>] __rmqueue+0x1a9/0x1e0 [<c015e651>] rmqueue_bulk+0x41/0x70 [<c015eae4>] get_page_from_freelist+0x464/0x490 [<c015ebba>] __alloc_pages_internal+0xaa/0x460 [<c015ef8f>] __alloc_pages+0xf/0x20 [<c015f4bf>] __get_free_pages+0xf/0x20 [<c01c015f>] proc_file_read+0x8f/0x2a0 [<c01c00d0>] proc_file_read+0x0/0x2a0 [<c01bb7ca>] proc_reg_read+0x5a/0x90 [<c01801f1>] vfs_read+0xa1/0x160 [<c01bb770>] pr...

...00000000 c0630a84 00000000 00000008 00000000 c1587418 c0630200 00000018 0000001f Call Trace: [<c015e2ea>] move_freepages_block+0x6a/0x80 [<c015e5d9>] __rmqueue+0x1a9/0x1e0 [<c015e651>] rmqueue_bulk+0x41/0x70 [<c015eae4>] get_page_from_freelist+0x464/0x490 [<c015ebba>] __alloc_pages_internal+0xaa/0x460 [<c015ef8f>] __alloc_pages+0xf/0x20 [<c015f4bf>] __get_free_pages+0xf/0x20 [<c01c015f>] proc_file_read+0x8f/0x2a0 [<c01c00d0>] proc_file_read+0x0/0x2a0 [<c01bb7ca>] proc_reg_read+0x5a/0x90 [<c01801f1>] vfs_read+0xa1/0x160 [<c01bb770>] pr...

...page c1326ca0) flags:0x00000068 mapping:cd26914c mapcount:0 count:2 Backtrace: [bad_page+112/176] bad_page+0x70/0xb0 [prep_new_page+60/96] prep_new_page+0x3c/0x60 [buffered_rmqueue+250/544] buffered_rmqueue+0xfa/0x220 [__set_page_dirty_nobuffers+170/272] __set_page_dirty_nobuffers+0xaa/0x110 [__alloc_pages+913/960] __alloc_pages+0x391/0x3c0 [generic_file_buffered_write+310/1520] generic_file_buffered_write+0x136/0x5f0 [current_fs_time+85/112] current_fs_time+0x55/0x70 [inode_update_time+75/192] inode_update_time+0x4b/0xc0 [__generic_file_aio_write_nolock+675/1232] __generic_file_aio_write_nolock+...

..., It seem that in the presence of several jornalling file systems in the kernel some mechanism is needed for proper sharing of the ->journal_info pointer in the task_struct. One journalled file system can indirectly call another during page fault in copy_from_user, quota file modification, or __alloc_pages()->balance_classzone()->shrink_cache()->vm_writeback() sequence. (Actually, I don't understand when prevents ext3 from re-entering itself in such a case.) Can we replace struct task_struct { ... void *journal_info; }; with struct fs_activation; struct fs_activation { stru...

...p_mask=0x201d2, order=0, oomkilladj=0 Apr 2 17:18:28 s_local at webmail kernel: Apr 2 17:18:28 s_local at webmail kernel:Call Trace: Apr 2 17:18:28 s_local at webmail kernel:[<ffffffff802bc998>] out_of_memory+0x8b/0x203 Apr 2 17:18:28 s_local at webmail kernel:[<ffffffff8020f657>] __alloc_pages+0x245/0x2ce Apr 2 17:18:28 s_local at webmail kernel:[<ffffffff8021336e>] __do_page_cache_readahead+0xd0/0x21c Apr 2 17:18:28 s_local at webmail kernel:[<ffffffff80262824>] __wait_on_bit_lock+0x5b/0x66 Apr 2 17:18:28 s_local at webmail kernel:[<ffffffff88081d4d>] :dm_mod:dm_...

...machine. The data resides on my Linux server running Debian, selfmade kernel 2.6.8.1 and samba 3.0.6. After a while the syslog showed lines like these: ---snip---- Aug 27 19:27:38 sauron kernel: smbd: page allocation failure. order:5, mode:0xd0 Aug 27 19:27:38 sauron kernel: [<c0134648>] __alloc_pages+0x2f8/0x370 Aug 27 19:27:38 sauron kernel: [<c01346df>] __get_free_pages+0x1f/0x40 Aug 27 19:27:38 sauron kernel: [<c0137b6f>] kmem_getpages+0x1f/0xd0 Aug 27 19:27:38 sauron kernel: [<c01387da>] cache_grow+0xba/0x180 Aug 27 19:27:38 sauron kernel: [<c0138a0a>] cache_allo...

...4:02:03 lvs2 kernel: Backtrace: Jul 3 04:02:03 lvs2 kernel: [<c014eaad>] bad_page+0x58/0x89 Jul 3 04:02:03 lvs2 kernel: [<c014eeba>] prep_new_page+0x24/0x3a Jul 3 04:02:03 lvs2 kernel: [<c014f51f>] buffered_rmqueue+0x1c4/0x1e7 Jul 3 04:02:03 lvs2 kernel: [<c014f5f5>] __alloc_pages+0xb3/0x29a Jul 3 04:02:03 lvs2 kernel: [<c01604df>] anon_vma_prepare+0x1f/0x1bf Jul 3 04:02:03 lvs2 kernel: [<c015ad3a>] do_wp_page+0x1d4/0x422 Jul 3 04:02:03 lvs2 kernel: [<c015bf5c>] handle_mm_fault+0x136/0x212 Jul 3 04:02:03 lvs2 kernel: [<c011d967>] do_page_fault...

...ment it yourself for the iommu case: { merge_boundary = dma_get_merge_boundary(dev); if (!merge_boundary || merge_boundary > chunk_size - 1) { /* can't coalesce */ return -EINVAL; } nents = DIV_ROUND_UP(total_size, chunk_size); sg = sgl_alloc(); for_each_sgl() { sg->page = __alloc_pages(get_order(chunk_size)) sg->len = chunk_size; } dma_map_sg(sg, DMA_ATTR_SKIP_CPU_SYNC); // you are guaranteed to get a single dma_addr out } Of course this still uses the scatterlist structure with its annoying mix of input and output parametes, so I'd rather not expose it as an officia...

...; Trace; c014c100 <dispose_list+40/60> Trace; c014c359 <prune_icache+b9/e0> Trace; c014c3a0 <shrink_icache_memory+20/40> Trace; c012fafe <shrink_caches+6e/90> Trace; c012fb5c <try_to_free_pages+3c/60> Trace; c01304ce <balance_classzone+5e/1b0> Trace; c013073b <__alloc_pages+11b/180> Trace; c0128f69 <do_generic_file_read+349/460> Trace; c01293cc <generic_file_read+7c/130> Trace; c0129270 <file_read_actor+0/e0> Trace; c01506f1 <read_dquot+91/100> Trace; c0150c9f <dqget+15f/1e0> Trace; c0151856 <dquot_initialize+a6/180> Trace; c015c...

...2a0 Nov 1 13:52:13 localhost kernel: [add_to_page_cache+112/208] add_to_page_cache+0x70/0xd0 Nov 1 13:52:13 localhost kernel: [read_pages+241/320] read_pages +0xf1/0x140 Nov 1 13:52:13 localhost kernel: [blkdev_get_block+0/96] blkdev_get_block+0x0/0x60 Nov 1 13:52:13 localhost kernel: [__alloc_pages+739/1056] __alloc_pages+0x2e3/0x420 Nov 1 13:52:13 localhost kernel: [__do_page_cache_readahead +247/400] __do_page_cache_readahead+0xf7/0x190 Nov 1 13:52:13 localhost kernel: [blockable_page_cache_readahead +58/128] blockable_page_cache_readahead+0x3a /0x80 Nov 1 13:52:13 localhost kernel...

...It looks like I still have plenty of swap left, so why the page allocation failure? Thanks for any enlightenment. VM isn't my strong suit. -Steve ======= Sep 20 13:34:33 hagar kernel: metacity: page allocation failure. order:0, mode:0x50 Sep 20 13:34:33 hagar kernel: [<c0144257>] __alloc_pages+0x28b/0x29d Sep 20 13:34:33 hagar kernel: [<c01408da>] find_lock_page+0x96/0x9d Sep 20 13:34:33 hagar kernel: [<c014091a>] find_or_create_page +0x39/0x72 Sep 20 13:34:33 hagar kernel: [<c015cde3>] grow_dev_page+0x26/0x102 Sep 20 13:34:33 hagar kernel: [<c015cf8e>] __getb...

...Xen zones directly, but clogs up the Xen web1 console etc. We did not see this when running the 2.6.18-8.1.8 Xen kernel, instead the Xen zones crashed less frequent with a out of memory problem as follows: Call Trace: [<ffffffff802aeefc>] out_of_memory+0x4e/0x1d3 [<ffffffff8020efe8>] __alloc_pages+0x229/0x2b2 [<ffffffff8023fd5b>] __lock_page+0x5e/0x64 [<ffffffff80232637>] read_swap_cache_async+0x42/0xd1 [<ffffffff802b32a2>] swapin_readahead+0x4e/0x77 [<ffffffff8020929d>] __handle_mm_fault+0xae3/0xf46 [<ffffffff80260709>] _spin_lock_irqsave+0x9/0x14 [<ff...

...Xen zones directly, but clogs up the Xen web1 console etc. We did not see this when running the 2.6.18-8.1.8 Xen kernel, instead the Xen zones crashed less frequent with a out of memory problem as follows: Call Trace: [<ffffffff802aeefc>] out_of_memory+0x4e/0x1d3 [<ffffffff8020efe8>] __alloc_pages+0x229/0x2b2 [<ffffffff8023fd5b>] __lock_page+0x5e/0x64 [<ffffffff80232637>] read_swap_cache_async+0x42/0xd1 [<ffffffff802b32a2>] swapin_readahead+0x4e/0x77 [<ffffffff8020929d>] __handle_mm_fault+0xae3/0xf46 [<ffffffff80260709>] _spin_lock_irqsave+0x9/0x14 [<ff...

...mask = 0700 directory security mask = 0700 admin users = PROD\???????? -- I issed the following command, with these results: -- hebe root # net ads join -U btimby btimby's password: Killed -- And in my syslog: -- hebe root # tail -n 2 /var/log/messages May 25 08:39:58 hebe __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) May 25 08:39:59 hebe VM: killing process net -- Funny that it seems ALL my memory gets used up! before: -- hebe root # vmstat -s 256812 total memory 27520 used memory 2192 active memory 5624 inactive memory...