This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM1808 - ubiformat fails when free ram space is limited

Other Parts Discussed in Thread: AM1808

Hi,

I’m working on a embedded linux project based on ARM9 TI AM1808.

I have the following problem when writing an UBI image with ubiformat when free RAM space is limited.

root@am180x-evm:/home# ubiformat -q -s 2048 -f rootfs.ubi /dev/mtd5 -O 2048
ubiformat: page allocation failure. order:5, mode:0x40d0
Backtrace:
[<c00454e4>] (dump_backtrace+0x0/0x110) from [<c0397a4c>] (dump_stack+0x18/0x1c)
r6:00000001 r5:00000005 r4:000040d0 r3:00000002
[<c0397a34>] (dump_stack+0x0/0x1c) from [<c0095644>] (__alloc_pages_nodemask+0x510/0x578)
[<c0095134>] (__alloc_pages_nodemask+0x0/0x578) from [<c00956c4>] (__get_free_pages+0x18/0x44)
[<c00956ac>] (__get_free_pages+0x0/0x44) from [<c00bcb80>] (__kmalloc+0x3c/0xcc)
[<c00bcb44>] (__kmalloc+0x0/0xcc) from [<c0235274>] (mtd_write+0x84/0x208)
r8:003a0000 r7:c4d11f70 r6:c79ac800 r5:0001f800 r4:0001f800
r3:00000000
[<c02351f0>] (mtd_write+0x0/0x208) from [<c00bf900>] (vfs_write+0xbc/0x148)
[<c00bf844>] (vfs_write+0x0/0x148) from [<c00bfb84>] (sys_write+0x44/0x70)
r8:0001f800 r7:00000000 r6:003a0000 r5:beb70990 r4:c7b84b00
[<c00bfb40>] (sys_write+0x0/0x70) from [<c0041fa0>] (ret_fast_syscall+0x0/0x2c)
r8:c0042124 r7:00000004 r6:00000000 r5:00000000 r4:beb90a90
Mem-info:
DMA per-cpu:
CPU 0: hi: 42, btch: 7 usd: 34
active_anon:2104 inactive_anon:111 isolated_anon:0
active_file:1838 inactive_file:24730 isolated_file:0
unevictable:0 dirty:0 writeback:0 unstable:0
free:642 slab_reclaimable:531 slab_unreclaimable:631
mapped:3511 shmem:180 pagetables:116 bounce:0
DMA free:2600kB min:1440kB low:1800kB high:2160kB active_anon:8416kB inactive_anon:444kB active_file:7352kB inactive_file:98920kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:130048kB mlocked:0kB dirty:0kB writeback:0kB mapped:14044kB shmem:720kB slab_reclaimable:2124kB slab_unreclaimable:2472kB kernel_stack:472kB pagetables:464kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 256*4kB 59*8kB 13*16kB 8*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 2600kB
26748 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
32768 pages of RAM
798 free pages
1513 reserved pages
874 slab pages
5231 pages shared
0 pages swap cached
libmtd: error!: cannot write 129024 bytes to mtd5 (eraseblock 29, offset 0)
error 12 (Cannot allocate memory)
ubiformat: error!: cannot write eraseblock 29
error 12 (Cannot allocate memory)
root@am180x-evm:/home#

I'm using mtd-utils 1.5.0.

Please, can anyone help ?

Gabriele

  • Did you find answer to this question? Can you update here?

  • Hi,

    unfortunately I did not find a answer to this question.

    Gabriele

  • May be I can give you some inputs, if you are interested. 
    Please can you list down few properties here? 

    1. RAM size
    2. Default mem allowed for kernel [check you boot args]
    3. Size of ubi.img
    4. ubinize.config config file.
    5. and mkfs.ubifs and ubinize commands.
  • Hi,

    it's strange. For a long time I ignored this issue. Today I tested it many times and it seems to works well!

    Take a look:

    root@am180x-evm:~# ls -la rootfs.ubi
    -rw-rw-r-- 1 1000 1000 190578688 Feb 4 2014 rootfs.ubi
    root@am180x-evm:~# flash_erase -q /dev/mtd5 0 0
    root@am180x-evm:~# free -m
    total used free shared buffers
    Mem: 125468 123252 2216 0 0
    -/+ buffers: 123252 2216
    Swap: 0 0 0
    root@am180x-evm:~# ubiformat -q -s 2048 -f rootfs.ubi /dev/mtd5 -O 2048
    root@am180x-evm:~# free
    total used free shared buffers
    Mem: 125468 123476 1992 0 0
    -/+ buffers: 123476 1992
    Swap: 0 0 0
    root@am180x-evm:~#

    In the meanwhile I moved from kernel v2.6.37 to v3.3.0. Pheraps the bug was kernel related and it has been fixed. Who knows ?!

    Thanks!

    Gabriele

  • Filosofi ,

    Yes may be it is fixed in latest kernel, I am not sure. but yes  it need some tweeks in old kernel.

    It may work fine on old kernel also, if you provide enough space for kerne on RAM.

    -Ravikiran