linux c6x expectations - evm 6678 like target

Ok - zero interest in this post. A little follow up: (Note - stock Linux-c6x-2.0.0.63)

I've managed to get a 32MB c6x image to boot by preventing the kernel from freeing init memory. This area of memory in the kernel is supposed to be referenced only by the kernel_init thread during boot. The memory (text and data) is then freed and added to the available pool of pages for kmalloc and friends. (it only frees some 120k for me).

It would appear that something in the init section is actually referenced later on once we have booted. As soon as a kmalloc reaches into this area the problems above occur. In the case of the 32MB case - we don't even get a shell.

Although no one has shown any interest here - it's likely that this issue will appear eventually on kernel builds with much more memory. 

Kernel debugging. Now we're having fun.... not

Hi Lan,

Sorry for the delayed response.

Actually our team looking into your problem.

You would get support soon.

Have you tried to boot through over network ie NFS to confirm that the problem is due to size of flash ?

What is the size of filesystem location and size of the initramfs after unzipped (ie with files & folders) ?

Hi,

This is a pure initramfs so no flash fs is involved. It's loaded into ram via our own bootloader.

The kernel+compressed fs is 9.5MB. the initramfs cpio.gz is 4.3MB which is succesfully freed once the ram based fs is created in memory. Once booted (with free_initmem() commented out in main.c) I have 13MB used and 15MB free.

Once booted - the fs occupies 9.4MB (# du -h ) The kernel is aprox 4MB. This adds up to the 13MB mentioned above (# free ).

As i pointed out - it seems that freeing init ram for kmalloc to use causes the problem. Throwing more memory at the image means that the init ram is either never used or used once a system gets busy enough.

Ian

Hi, Ian,

Linux-c6x does not support MMU and when kernel boots up, it will need to load as much as what might be used later to the memory. You may want to use the max memory to find out how much actually used by racoon. With embedded Linux without MMU, there is limitation on how things to fit in limited resource.

Rex

Hi Rex,

I'm well aware that c6x is a no-mmu linux. My point here is that I could not boot in 32MB and found that with 48MB the system was unreliable (I could in fact crash a 48MB system simply using du|sort and ls). Many failures to mmap shared libraries as shown in my first post.

After much effort debugging the kernel memory management, when I noticed that kmalloc was allocating memory within the kernel - I decided to try disabling the freeing of __init section ram. This fixed the issues in 48MB and also allowed me to boot successfully in 32MB. Now that's counter intuitive in a ram constrained system.

I'm now booting in 32MB with 140k less memory as it's not being freed. And running a fairly stressful test (see below) within a 32MB budget. I decided to use the openssl command line tool as it does not need a config. It's about as large as racoon and it also statically links to libcrypto (the open ssl library) which racoon uses.

So - I conclude that this is a kernel bug that manifests itself in very low memory configurations. There is very little that needs to be changed to test this on a vanilla evm667[8,0]. Just 2 files. Having spent 2 weeks chasing this issue - I must now move on to application code. (but I would like to avoid the disabling of free_initmem(); in ./init/main.c)

/ # free
     total used free shared buffers
Mem: 28612 13780 14832 0 0
/ #

In the test below - I'm running 6 copies of openssl command line tool running a md5 speed test (backgrounded). This in 32MB of ram. Note - still have 8MB free. This test is run in a loop 20 times with no failures to mmap a shared lib.

Mem: 19724K used, 8888K free, 0K shrd, 0K buff, 10296K cached
CPU: 99% usr 0% sys 0% nic 0% idle 0% io 0% irq 0% sirq
Load average: 3.44 1.26 0.45 7/26 118
PID PPID USER STAT VSZ %MEM %CPU COMMAND
112 81 root R 3730 13% 17% openssl speed md5
113 81 root R 3730 13% 17% openssl speed md5
115 81 root R 3730 13% 17% openssl speed md5
116 81 root R 3730 13% 17% openssl speed md5
117 81 root R 3730 13% 17% openssl speed md5
114 81 root R 3730 13% 16% openssl speed md5
81 65 root S 1216 4% 0% sh /usr/local/bin/icc
65 1 root S 1212 4% 0% /bin/sh
104 65 root R 1196 4% 0% top
1 0 root S 1188 4% 0% init
63 1 root S 1188 4% 0% inetd
118 81 root S 1184 4% 0% sleep 25
2 0 root SW 0 0% 0% [kthreadd]
14 2 root SW 0 0% 0% [mtdblockd]
15 2 root SW 0 0% 0% [kpktgend_0]
3 2 root SW 0 0% 0% [ksoftirqd/0]
4 2 root SW 0 0% 0% [events/0]
5 2 root SW 0 0% 0% [khelper]
6 2 root SW 0 0% 0% [async/mgr]
27852 md5's in 0.50s SW 0 0% 0% [sync_supers]
Doing md5 for 3s on 8192 size blocks: 27873 md5's in 0.50s
Doing md5 for 3s on 8192 size blocks: 27647 md5's in 0.50s
Doing md5 for 3s on 8192 size blocks: 27794 m