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調試（二）》 吧。