Last time I've seem such errors I also suspected a memory issue.
In the end however, it was caused by buggy nic firmware so if the above won't help, here is another option.
Main Topics
Browse All TopicsWe're getting pretty much a "continuous flood" of the informational message below on a SUSE OpenLinux box running the CA BrightStor ArcServe 11.5 SP3 client and communicating with a Windows box running the full version of ArcServe (same version and patch level).
Anyone have any ideas on how to diagnose or fix this? More info as requested...
-----------------------
The following is only an harmless informational message.
Unless you get a _continuous_flood_ of these messages it means
everything is working fine. Allocations from irqs cannot be
perfectly reliable and the kernel is designed to handle that.
swapper: page allocation failure. order:0, mode:0x20
Call Trace:
<IRQ> [<ffffffff8020dc1e>] __alloc_pages+0x2d8/0x2f1
[<ffffffff80215375>] cache_grow+0x137/0x343
[<ffffffff802573fd>] cache_alloc_refill+0x17e/0
[<ffffffff802bdf50>] __kmalloc+0x95/0x9f
[<ffffffff8022c3ac>] __alloc_skb+0x5c/0x123
[<ffffffff80395011>] __netdev_alloc_skb+0x12/0x
[<ffffffff88173238>] :e1000:e1000_alloc_rx_buff
[<ffffffff881739c6>] :e1000:e1000_clean_rx_irq+
[<ffffffff88172414>] :e1000:e1000_clean+0x84/0x
[<ffffffff8020b9a2>] net_rx_action+0xa4/0x1b0
[<ffffffff8020fef1>] __do_softirq+0x5e/0xd5
[<ffffffff8031db46>] end_msi_irq_wo_maskbit+0x9
[<ffffffff802591e4>] call_softirq+0x1c/0x28
[<ffffffff80265da2>] do_softirq+0x2c/0x7d
[<ffffffff80265d6d>] do_IRQ+0x6a/0x73
[<ffffffff80252cae>] mwait_idle+0x0/0x4a
[<ffffffff80258509>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff80252ce4>] mwait_idle+0x36/0x4a
[<ffffffff802451ba>] cpu_idle+0x95/0xb8
[<ffffffff805da7a3>] start_kernel+0x21b/0x220
[<ffffffff805da28a>] _sinittext+0x28a/0x28e
Mem-info:
Node 0 DMA per-cpu:
cpu 0 hot: high 0, batch 1 used:0
cpu 0 cold: high 0, batch 1 used:0
cpu 1 hot: high 0, batch 1 used:0
cpu 1 cold: high 0, batch 1 used:0
Node 0 DMA32 per-cpu:
cpu 0 hot: high 186, batch 31 used:30
cpu 0 cold: high 62, batch 15 used:51
cpu 1 hot: high 186, batch 31 used:20
cpu 1 cold: high 62, batch 15 used:10
Node 0 Normal per-cpu: empty
Node 0 HighMem per-cpu: empty
Free pages: 3804kB (0kB HighMem)
Active:195589 inactive:295150 dirty:57148 writeback:1 unstable:0 free:951 slab:18829 mapped:4486 pagetables:524
Node 0 DMA free:1756kB min:32kB low:40kB high:48kB active:0kB inactive:0kB present:11572kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2000 2000 2000
Node 0 DMA32 free:2048kB min:5704kB low:7128kB high:8556kB active:782356kB inactive:1180600kB present:2048920kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 3*4kB 4*8kB 3*16kB 2*32kB 1*64kB 2*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1756kB
Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2048kB
Node 0 Normal: empty
Node 0 HighMem: empty
Swap cache: add 31, delete 31, find 0/0, race 0+0
Free swap = 4008056kB
Total swap = 4008176kB
Free swap: 4008056kB
524032 pages of RAM
9707 reserved pages
398871 pages shared
0 pages swap cached
The following is only an harmless informational message.
Unless you get a _continuous_flood_ of these messages it means
everything is working fine. Allocations from irqs cannot be
perfectly reliable and the kernel is designed to handle that.
klogd: page allocation failure. order:0, mode:0x20
Call Trace:
<IRQ> [<ffffffff8020dc1e>] __alloc_pages+0x2d8/0x2f1
[<ffffffff80215375>] cache_grow+0x137/0x343
[<ffffffff802573fd>] cache_alloc_refill+0x17e/0
[<ffffffff802bdf50>] __kmalloc+0x95/0x9f
[<ffffffff8022c3ac>] __alloc_skb+0x5c/0x123
[<ffffffff80395011>] __netdev_alloc_skb+0x12/0x
[<ffffffff88173238>] :e1000:e1000_alloc_rx_buff
[<ffffffff88173965>] :e1000:e1000_clean_rx_irq+
[<ffffffff88172414>] :e1000:e1000_clean+0x84/0x
[<ffffffff8020b9a2>] net_rx_action+0xa4/0x1b0
[<ffffffff8020fef1>] __do_softirq+0x5e/0xd5
[<ffffffff8031db46>] end_msi_irq_wo_maskbit+0x9
[<ffffffff802591e4>] call_softirq+0x1c/0x28
[<ffffffff80265da2>] do_softirq+0x2c/0x7d
[<ffffffff80265d6d>] do_IRQ+0x6a/0x73
[<ffffffff80258509>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff80284338>] do_syslog+0x173/0x3be
[<ffffffff8028434f>] do_syslog+0x18a/0x3be
[<ffffffff80292876>] autoremove_wake_function+0
[<ffffffff802e5105>] kmsg_read+0x3a/0x44
[<ffffffff8020a9d1>] vfs_read+0xcb/0x171
[<ffffffff8020f72f>] sys_read+0x45/0x6e
[<ffffffff8025800e>] system_call+0x7e/0x83
Mem-info:
Node 0 DMA per-cpu:
cpu 0 hot: high 0, batch 1 used:0
cpu 0 cold: high 0, batch 1 used:0
cpu 1 hot: high 0, batch 1 used:0
cpu 1 cold: high 0, batch 1 used:0
Node 0 DMA32 per-cpu:
cpu 0 hot: high 186, batch 31 used:30
cpu 0 cold: high 62, batch 15 used:51
cpu 1 hot: high 186, batch 31 used:20
cpu 1 cold: high 62, batch 15 used:10
Node 0 Normal per-cpu: empty
Node 0 HighMem per-cpu: empty
Free pages: 3804kB (0kB HighMem)
Active:195589 inactive:295150 dirty:57148 writeback:1 unstable:0 free:951 slab:18829 mapped:4486 pagetables:524
Node 0 DMA free:1756kB min:32kB low:40kB high:48kB active:0kB inactive:0kB present:11572kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2000 2000 2000
Node 0 DMA32 free:2048kB min:5704kB low:7128kB high:8556kB active:782356kB inactive:1180600kB present:2048920kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 3*4kB 4*8kB 3*16kB 2*32kB 1*64kB 2*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1756kB
Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2048kB
Node 0 Normal: empty
Node 0 HighMem: empty
Swap cache: add 31, delete 31, find 0/0, race 0+0
Free swap = 4008056kB
Total swap = 4008176kB
Free swap: 4008056kB
524032 pages of RAM
9707 reserved pages
398871 pages shared
0 pages swap cached
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Thanks, we'll look into it.
I tested the memory before the server went online and it was ok (just a couple months ago), so I'm going to guess the issue may be quantity. The server currently has 2GB, but we are dragging TBs of data in and out of it sometimes.
I can try slapping another 2GB in and testing the whole setup. We'll see what happens.
Finally, some followup.
I think the primary issue was memory allocation. According to 3Ware and Red Hat (the two places I found references), the default value for "min_free_kbytes" can be too small in the default kernel allocation. This could be fixed by adding more system memory, as ravenpl suggested, or by editing the value in /etc/sysctl.conf.
We added the line below to our configuration file and it has addressed this issue:
vm.min_free_kbytes=16384
We're still having some data transfer issues, but I think they're related to us push/pulling from a Windows 32-bit system to/from our 64-bit Linux box with it's huge partitiion (5TB). If that continues I'll be asking another question...
Business Accounts
Answer for Membership
by: ravenplPosted on 2007-11-02 at 11:31:34ID: 20203279
You either have too few memory (and it cannot allocate large buffers), or the memory is broken.
To check memory http://www.memtest.org/