DM365+EC122调试（一）

硬件平台：瑞泰DM365开发板

开发板内核：Linux 2.6.18

DVSDK版本：2_10_00_17

//

问题1：

root@192.168.1.3:~# usb 1-1.2: USB disconnect, address 4
printk: 1 messages suppressed.
oom-killer: gfp_mask=0x201d2, order=0
Mem-info:
DMA per-cpu:
cpu 0 hot: high 18, batch 3 used:2
cpu 0 cold: high 6, batch 1 used:0
DMA32 per-cpu: empty
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages:        1296kB (0kB HighMem)
Active:2465 inactive:116 dirty:0 writeback:0 unstable:0 free:296 slab:841 mapped:117 pagetables:281
DMA free:1184kB min:1068kB low:1332kB high:1600kB active:9888kB inactive:548kB present:71680kB pages_scanned:1219 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA32 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
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
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
DMA: 47*4kB 32*8kB 0*16kB 1*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 1116kB
DMA32: empty
Normal: empty
HighMem: empty
Swap cache: add 0, delete 0, find 0/0, race 0+0

//

    开发板通过NFS加载的是虚拟机中的文件系统。

    使用 usb_modeswitch 和 wvdial 配合调试3G（EC122）模块。

    无论是使用自己的制作的NFS文件系统，还是使用瑞泰自带的NFS文件系统，在运行 usb_modeswitch -W 时偶尔会出现如上的信息。经过努力搜索资料，初步认为是OOM（Out Of Memory）Killer引起的。

    于是搜索OOM Killer 与 MD365，期间查到一些与OOM Killer有关的东西，比如

*********************************************************************参考链接一**********************************************************************************

关于oom killer的问题

        Out-of-Memory(OOM) Killer，就是一层保护机制，用于避免 Linux 在内存不足的时候不至于出太严重的问题，把无关紧要的进程杀掉。
　　
　　在 32 位CPU 架构下寻址是有限制的。Linux 内核定义了三个区域：
　　# DMA: 0×00000000 – 0×00999999 (0 – 16 MB)
　　# LowMem: 0×01000000 – 0×037999999 (16 – 896 MB) – size: 880MB
　　# HighMem: 0×038000000 -
　　
　　什么时候会触发oom killer？大概就两种情况：
　　1、当low memory被耗尽的时候，即使high memory还有很大的空闲内存
　　2、low memory里都是碎片，请求不到连续的内存区域
　　
　　通常的问题是high memory很大仍然会触发oom killer，或者由于碎片触发oom killer，解决办法：
　　1、升级至64位的Linux 版本，这是最好的解决方案。
　　2、如果是32位的Linux 版本，最好的解决办法就是应用hugemem kernel，还有一个解决方法设置/proc/sys/vm/lower_zone_protection值为250或更高。
　　# echo “250″ > /proc/sys/vm/lower_zone_protection
　　设置成启动加载，在/etc/sysctl.conf中加入
　　vm.lower_zone_protection = 250
　　3、最无力的解决办法，就是禁用oom-killer，这可能会导致系统挂起，所以要慎重使用。
　　使oom-killer关闭/开启:
　　# echo “0″ > /proc/sys/vm/oom-kill
　　# echo “1″ > /proc/sys/vm/oom-kill
　　使设置启动时生效，需要在/etc/sysctl.conf中加入
　　vm.oom-kill = 0
　　
        【关于overcommit_memory】
　　
　　The Linux kernel supports the following overcommit handling modes
　　0 – Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
　　1 – Always overcommit. Appropriate for some scientific applications.
　　2 – Don’t overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate.
　　
　　The overcommit policy is set via the sysctl `vm.overcommit_memory’.
　　The overcommit percentage is set via `vm.overcommit_ratio’.
　　The current overcommit limit and amount committed are viewable in
　　/proc/meminfo as CommitLimit and Committed_AS respectively.
　　——————————————————————————————
　　#echo 2>/proc/sys/vm/overcommit_memory
　　#echo 0>/proc/sys/vm/overcommit_ratio
　　——————————————————————————————
　　实际测试：
　　overcommit_memory == 2，物理内存使用完后，打开任意一个程序均显示“内存不足”；
　　overcommit_memory == 1，会从buffer中释放较多物理内存，适合大型科学应用软件，但oom-killer机制仍然起作用；
　　overcommit_memory == 0，系统默认设置，释放物理内存较少，使得oom-killer机制运作很明显。
From - http://zhangsir.org/?p=213

*********************************************************************参考链接二**********************************************************************************

You are lucky - I spent several weeks to solve this.

In brief - issue the following commands to solve this:

sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=90
sysctl -w vm.dirty_ratio=10

For the help search Internet for these parameters.

Regards

Form - http://e2e.ti.com/support/embedded/linux/f/354/t/124193.aspx

*********************************************************************华丽的分割线**********************************************************************************

    参考了上述自我感觉很有用的资料，也在瑞泰DM365开发板上做尝试，但是结果令人遗憾，问题依旧。

    此时，我已经快到了崩溃的边缘，与此同时，实验室又有人提议明天要去爬山。哦，我的神啊，最近实验一直出问题，我哪里有心情出去玩啊！

    临近崩溃边缘的我做最后的挣扎。我尝试使用NandFlash上的文件系统试试。

    究竟使用NandFlash上的文件系统进展的如何？进入 《DM365+EC122调试（二）》 吧。