Has anyone encountered this error before?

Altera_Forum · ‎07-06-2009

Hello folks,

I am getting this error frequently when testing an application on the DE2 and uClinux. It happens when calling a command . In my case, it happens with ftpput, which is the one I am using, but it has also happened with mv, cp, touch, among others.

Below are a few examples. It is weird because I try to check constantly (as a test to see available memory) as the application is running and there are about 2M still free from the SDRAM. Sometimes he whole system freezes, and others only the called command is not executed, but the rest of the processes continue normally.

Thanks in advance,

Francisco

Below are two examples:

cp /logs/buffer1.txt /buffertemp.txt
cp: page allocation failure. order:7, mode:0xd0
Stack from 00f45da0:<0>
       <0> 00000007<0> 0084b4e0<0> 00000001<0> 00000048<0> 00000000<0> 00000000<0> 00000001<0> 00000000<0>
       <0> 000200d0<0> 00a3e838<0> 00000002<0> 00046000<0> 00000001<0> 00a4745c<0> 00e14e8c<0> 00000000<0>
       <0> 00000007<0> 00a28b38<0> 00000000<0> 00857af8<0> 00a44c60<0> 00000004<0> 00868b80<0> 00868bac<0>
       <0> 00046000<0> 00000007<0> 00000005<0> 00003f07<0> 00006690<0> 000373e0<0> 00000005<0> 00000004<0>
       <0> 0000da00<0> ffffe000<0> 00e13e00<0> 0089f624<0> 00000002<0> 00000000<0> 00849eb4<0> 00000000<0>
       <0> 00000001<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0>
Call Trace:<0>
       <0> <0> <0> <0> <0>
       <0> <0> <0> <0> <0>
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Active_anon:0 active_file:0 inactive_anon:0
 inactive_file:17 unevictable:402 dirty:0 writeback:0 unstable:0
 free:669 slab:158 mapped:0 pagetables:0 bounce:0
DMA free:2676kB min:360kB low:448kB high:540kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:68kB unevictable:1608kB present:8128kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve: 0 0 0
DMA: 1*4kB 2*8kB 2*16kB 10*32kB 6*64kB 5*128kB 5*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 2676kB
419 total pagecache pages
0 pages RAM
0 pages reserved
0 pages shared
0 pages non-shared
Allocation of length 286720 from process 56 (cp) failed
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Active_anon:0 active_file:0 inactive_anon:0
 inactive_file:17 unevictable:402 dirty:0 writeback:0 unstable:0
 free:669 slab:158 mapped:0 pagetables:0 bounce:0
DMA free:2676kB min:360kB low:448kB high:540kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:68kB unevictable:1608kB present:8128kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve: 0 0 0
DMA: 1*4kB 2*8kB 2*16kB 10*32kB 6*64kB 5*128kB 5*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 2676kB
419 total pagecache pages
Unable to allocate RAM for process text/data, errno 12

ftpput -u uClinux -p pass 192.168.1.68 /home/ftp/uClinux/Desktop/logs/nodejemos /buffertemp.txt &
/> ftpput: page allocation failure. order:7, mode:0xd0
Stack from 00ec3da0:<0>
       <0> 00000007<0> 0084b4e0<0> 00000001<0> 00000048<0> 00000000<0> 00000000<0> 00000001<0> 00000000<0>
       <0> 000200d0<0> 00a3e838<0> 00000002<0> 00046000<0> 00000001<0> 00a4745c<0> 00e146fc<0> 00000000<0>
       <0> 00000007<0> 00a28b38<0> 00000000<0> 00857af8<0> 00a44c60<0> 00000004<0> 00868b80<0> 00868bac<0>
       <0> 00046000<0> 00000007<0> 00000005<0> 00003f5e<0> 00006690<0> 000373e0<0> 00000005<0> 00000004<0>
       <0> 0000da00<0> ffffe000<0> 00e13e00<0> 0089f624<0> 00000002<0> 00000000<0> 00849eb4<0> 00000000<0>
       <0> 00000001<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0> 00000000<0>
Call Trace:<0>
       <0> <0> <0> <0> <0>
       <0> <0> <0> <0> <0>
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Active_anon:0 active_file:6 inactive_anon:0
 inactive_file:10 unevictable:403 dirty:0 writeback:0 unstable:0
 free:661 slab:163 mapped:0 pagetables:0 bounce:0
DMA free:2644kB min:360kB low:448kB high:540kB active_anon:0kB inactive_anon:0kB active_file:24kB inactive_file:40kB unevictable:1612kB present:8128kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve: 0 0 0
DMA: 1*4kB 0*8kB 1*16kB 10*32kB 6*64kB 5*128kB 5*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 2644kB
419 total pagecache pages
0 pages RAM
0 pages reserved
0 pages shared
0 pages non-shared
Allocation of length 286720 from process 50 (ftpput) failed
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Active_anon:0 active_file:6 inactive_anon:0
 inactive_file:10 unevictable:403 dirty:0 writeback:0 unstable:0
 free:661 slab:163 mapped:0 pagetables:0 bounce:0
DMA free:2644kB min:360kB low:448kB high:540kB active_anon:0kB inactive_anon:0kB active_file:24kB inactive_file:40kB unevictable:1612kB present:8128kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve: 0 0 0
DMA: 1*4kB 0*8kB 1*16kB 10*32kB 6*64kB 5*128kB 5*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 2644kB
419 total pagecache pages
Unable to allocate RAM for process text/data, errno 12

Altera_Forum · ‎07-08-2009

Francisco,

it seems that an application is trying to allocate 286720 bytes, but the largest contiguous memory block available is 256kB. uClinux is not able to "merge" these smaller chunks into the larger block that is being requested (I believe this is due to the lack of an MMU).

We started seeing similar errors in our system recently. And we are convinced that this is not due to any change in our application, so it appears that something changed recently under the hood in uClinux. In fact, this is starting to get me worried, since it leads to some subtle bugs in the graphics system (e.g., windows are not drawn because FLTK fails to allocate memory for a bitmap).

Anyone cares to guess what might have changed recently that could be interfering with memory allocation? Any comments are appreciated.

Cheers,

Ricardo.

Altera_Forum · ‎07-09-2009

If you're using a 2.6.30 kernel (not sure when it first appeared), the default kernel config contains:

(1) Turn on mmap() excess space trimming before booting

You should set this to 0 to help prevent memory fragmentation.

This setting is also at /proc/sys/vm/nr_trim_pages.

Besides that, since kernel 2.6.27 (where I started on my nios2 project), I've been seeing that no matter what, over time, jffs2's write cache seems to cause memory fragmentation. I believe the memory that seems to be getting stuck is seen in /proc/meminfo as Unreclaimable.

Instead of just looking at /proc/meminfo, you should also keep an eye on /proc/buddyinfo.

/> cat /proc/buddyinfo

Node 0, zone DMA 37 13 9 3 1 1 2 2 0 0 0 0 0 0

That says there are 37 4KB pages available, 13 8KB pages available, 9 16KB pages available, 3 32KB pages available, etc.

Altera_Forum · ‎07-10-2009

you nailed it!

<div class='quotetop'>QUOTE (pandemic @ Jul 9 2009, 05:50 PM) <{post_snapback}> (index.php?act=findpost&pid=23052)</div>

--- Quote Start ---

If you're using a 2.6.30 kernel (not sure when it first appeared), the default kernel config contains:

(1) Turn on mmap() excess space trimming before booting

You should set this to 0 to help prevent memory fragmentation.[/b]

--- Quote End ---

Everytinhg worked fine on 2.6.27. The current version in my board is 2.6.30.

It is hard to say for sure that the problem is gone, since it did not occur 100% of the time. But I have tested it quite a lot and either it is solved now, or I'm really lucky today. ;)

Thanks a lot,

Ricardo.

Altera_Forum · ‎07-11-2009

Hello Jasinski and Pandemic.

So I've managed to find the mmap() option in KErnel Config ---> Processro Type and Features.

The application has been running for about an hour now and it hasn't had any problem again. Seems like this worked. I'll have to test it overnight just to be sure. It shouldn't collapse. However, I'll just leave it like that and let you know in the morning.

Thank you very much!

Francisco

Altera_Forum · ‎07-14-2009

It worked. :)