0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Kernel Crash的分析方法與硬件設(shè)計

Linux閱碼場 ? 來源:Linux閱碼場 ? 作者:Linux閱碼場 ? 2022-07-12 09:27 ? 次閱讀

簡介

任何系統(tǒng),硬件故障和軟件故障都不可避免。比如車載系統(tǒng),由于汽車行駛過程中的震動,發(fā)熱,電瓶饋電等,很容易影響電子元件的特性,這對設(shè)備是致命的影響,會直接改變程序邏輯及運行結(jié)果從而產(chǎn)生各種不可預(yù)測的異常情況,本文描述常見問題的排查方法幫助快速排查定位問題所在也提出一些系統(tǒng)性設(shè)計來規(guī)避這些問題.

啟動流程初判斷

我們對穩(wěn)定性分析第一手分析本上是從debug log開始,它可以直觀的給我們信息反饋, 想對debug log 中的問題進行判斷還需要我們對設(shè)備的啟動流程有充分的了解,在什么階段使用了哪些資源同時又有哪些硬件參與其中.

通過分割流程,細化加載過程可以對當(dāng)前疑問點從合理性進行解釋,以高通啟動為例:

4305b4a0-0177-11ed-ba43-dac502259ad0.png

B -    381616 - clock_init, StartD -       183 - clock_init, DeltaB -    381860 - Image Load, StartD -     87230 - QSEE Image Loaded, Delta - (1541808 Bytes)B -    469120 - Image Load, StartD -       335 - SEC Image Loaded, Delta - (2048 Bytes)B -    506391 - sbl1_efs_handle_cookies, StartD -       671 - sbl1_efs_handle_cookies, DeltaB -    508282 - Image Load, StartD -     12383 - DEVCFG Image Loaded, Delta - (55764 Bytes)B -    521184 - Image Load, StartD -     20099 - RPM Image Loaded, Delta - (180504 Bytes)B -    541314 - Image Load, StartD -     52277 - APPSBL Image Loaded, Delta - (579748 Bytes)B -    593621 - QSEE Execution, StartD -       122 - QSEE Execution, Delta

從啟動流程可以知道每一個階段的啟動都包含著數(shù)據(jù)完整性檢查,當(dāng)secboot開啟時還有合法性檢查; 通過這個幫助我們初步判斷異常位置明確下一步分析方向;

Nand Flash排查

針對nand flash的分析要先了解其構(gòu)造;

Flash的內(nèi)部存儲是MOSFET,里面有個懸浮門(Floating Gate),是真正存儲數(shù)據(jù)的單元。

數(shù)據(jù)在Flash內(nèi)存單元中是以電荷(electrical charge) 形式存儲的。存儲電荷的多少,取決于圖中的外部門(external gate)所被施加的電壓,其控制了是向存儲單元中沖入電荷還是使其釋放電荷。而數(shù)據(jù)的表示,以所存儲的電荷的電壓是否超過一個特定的閾值Vth來表示,因此,F(xiàn)lash的存儲單元的默認值,不是0(,而是1,而如果將電荷釋放掉,電壓降低到一定程度,表述數(shù)字0。

431d0bdc-0177-11ed-ba43-dac502259ad0.png

Nand Flash 存儲結(jié)構(gòu)

Nand 的缺點數(shù)據(jù)讀寫容易出錯,所以一般都需要有對應(yīng)的軟件或者硬件的數(shù)據(jù)校驗算法,統(tǒng)稱為ECC, 每一個頁,對應(yīng)還有一塊區(qū)域,叫做空閑區(qū)域(spare area)/冗余區(qū)域(redundant area),而Linux系統(tǒng)中,一般叫做OOB(Out Of Band),這個區(qū)域,是最初基于Nand Flash的硬件特性:數(shù)據(jù)在讀寫時候相對容易錯誤,所以為了保證數(shù)據(jù)的正確性,必須要有對應(yīng)的檢測和糾錯機制,此機制被叫做EDC(Error Detection Code)/ECC(Error Code Correction, 或者 Error Checking and Correcting),所以設(shè)計了多余的區(qū)域,用于放置數(shù)據(jù)的校驗值。

Oob的讀寫操作,一般是隨著頁的操作一起完成的,即讀寫頁的時候,對應(yīng)地就讀寫了oob。

關(guān)于oob具體用途,總結(jié)起來有:

1.標(biāo)記是否是壞快

2.存儲ECC數(shù)據(jù)

4336b168-0177-11ed-ba43-dac502259ad0.png

Nand Flash 結(jié)構(gòu)

壞塊

為什么會出現(xiàn)壞塊?

由于 NAND Flash的工藝不能保證NAND的Memory Array在其生命周期中保持性能的可靠,因此,在NAND的生產(chǎn)中及使用過程中會產(chǎn)生壞塊。壞塊的特性是:當(dāng)編程/擦除這個塊時,不能將某些位拉高,這會造成Page Program和Block Erase操作時的錯誤,相應(yīng)地反映到Status Register的相應(yīng)位。

壞塊的分類

總體上,壞塊可以分為兩大類

(1) 固有壞塊 這是生產(chǎn)過程中產(chǎn)生的壞塊,一般 芯片 原廠都會在出廠時都會將壞塊第一個page的spare area的第6個byte標(biāo)記為不等于0xff的值。

(2)使用壞塊 這是在NAND Flash使用過程中,如果Block Erase或者Page Program錯誤,就可以簡單地將這個塊作為壞塊來處理,這個時候需要把壞塊標(biāo)記起來。

壞塊如何檢測

壞塊的判斷方法非常簡單對目標(biāo)塊擦除就可判斷是否是壞塊。

壞塊的影響性

判斷壞塊并不是技術(shù)難點,問題是在于當(dāng)產(chǎn)生壞塊時系統(tǒng)穩(wěn)定性如何去保障,這里就涉及到項目前期對整體穩(wěn)定性設(shè)計;

根據(jù)固件格式大致可以分為三種:只讀鏡像,只讀文件系統(tǒng)和數(shù)據(jù)分區(qū)

1.只讀鏡像

這里只讀鏡像在固件中SBL ,LK,Boot.img 等等鏡像文件, 當(dāng)鏡像存儲區(qū)域由于某種異常產(chǎn)生壞塊就會破壞數(shù)據(jù)的完整性;

只讀鏡像大部分只會在加載過程中讀取,后續(xù)運行在內(nèi)存中,所以問題會在壞塊產(chǎn)生后的下一次啟動;

2.只讀文件系統(tǒng)

文件系統(tǒng)跟只讀鏡像比較類似,差別在于文件系統(tǒng)并不是一次全部加載校驗換句話說就是用哪里加載哪里,同樣原理如果加載數(shù)據(jù)因壞塊而導(dǎo)致失效系統(tǒng)也會崩潰;

3.數(shù)據(jù)分區(qū)

數(shù)據(jù)分區(qū)基本操作就是寫入和擦除,所以當(dāng)壞塊產(chǎn)生時影響的是在分區(qū)中存儲的數(shù)據(jù);

數(shù)據(jù)存儲根據(jù)使用功能的不同丟失的影響性也存在較大差異,文件系統(tǒng)中文件數(shù)據(jù)丟失表現(xiàn)為文件數(shù)據(jù)無法訪問或者文件不存在訪問失敗;但當(dāng)重要配置文件丟失, 證書文件,加密裸數(shù)據(jù)丟失同樣會導(dǎo)致系統(tǒng)崩潰無法正常使用;

預(yù)防性設(shè)計

萬幸的是使用過程中產(chǎn)生連續(xù)三個壞塊的概率極低,這就給我們機會針對壞塊預(yù)防性設(shè)計;

那我們?nèi)绾稳ソ鉀Q這個問題呢?

了解壞塊的產(chǎn)生和影響性,可以知道想要規(guī)避壞塊需要我們在系統(tǒng)設(shè)計初就要考慮,在設(shè)備使用過程中有壞塊產(chǎn)生時如何保證系統(tǒng)的穩(wěn)定性;

針對產(chǎn)生的影響性加強系統(tǒng)穩(wěn)定性設(shè)計:

1.只讀鏡像&只讀文件系統(tǒng)

加大分區(qū)冗余度是可以降低壞塊是在數(shù)據(jù)區(qū)的概率也會避免連續(xù)壞塊導(dǎo)致燒錄失敗但會加大空間損耗,不過由于只讀鏡像基本不大可以選擇加大冗余;

只是降低損壞概率還是完全無法保證系統(tǒng)的穩(wěn)定性, 鏡像分區(qū)設(shè)計可以幫助解決這個問題,通過啟動流程異常檢測可以幫助我們選擇完整分區(qū)進行加載并恢復(fù)損壞分區(qū);

2種設(shè)計可以大大增加系統(tǒng)整體的穩(wěn)定性,不過多分區(qū)設(shè)計要注意鄰區(qū)干擾要適當(dāng)?shù)姆珠_;

2.數(shù)據(jù)分區(qū)

根據(jù)存儲數(shù)據(jù)的必要性可以分為重要分區(qū)和普通分區(qū);

多分區(qū)設(shè)計也適用于重要分區(qū) 通過多個分區(qū)保存重要文件和數(shù)據(jù)可以避免數(shù)據(jù)缺失而引發(fā)的問題;

分區(qū)文件丟失通過備份分區(qū)恢復(fù)文件;

分區(qū)損壞先格式化問題分區(qū)后在通過備份分區(qū)恢復(fù)文件;

由于空間限制重要文件和數(shù)據(jù)要與普通分區(qū)

普通分區(qū)由于壞塊導(dǎo)致的異常完全可以通過格式化進行恢復(fù);

Nand Flash Bit Flip

由于Nand物理特性最常見的異常問題就是產(chǎn)生Bit Flip(位反轉(zhuǎn)) ;

什么是Bit Flip?

所謂的位反轉(zhuǎn),bit flip,指的是原先Nand Flash中的某個bit位,發(fā)生電容的0和1狀態(tài)的切換, 這種情況稱之為位反轉(zhuǎn)(Bit Flip)

Bit Flip 產(chǎn)生的原因?

借鑒業(yè)內(nèi)總結(jié)產(chǎn)生Bit Flip原因有如下幾種:

1.漂移效應(yīng)(Drifting Effects)

漂移效應(yīng)指的是,Nand Flash中cell的電壓值,慢慢地變了,變的和原始值不一樣了。

2.編程干擾所產(chǎn)生的錯誤(Program-Disturb Errors

此現(xiàn)象有時候也叫做,過度編程效應(yīng)(over-program effect)。 對于某個頁面的編程操作,即寫操作,引起非相關(guān)的其他的頁面的某個位跳變了。

3.讀操作干擾產(chǎn)生的錯誤(Read-Disturb Errors)

此效應(yīng)是,對一個頁進行數(shù)據(jù)讀取操作,卻使得對應(yīng)的某個位的數(shù)據(jù),產(chǎn)生了永久性的變化,即Nand Flash上的該位的值變了。

在Nand Flash使用過程中可以總結(jié)一下幾點:

1.讀取干擾:讀取 NAND flash page會對同一塊中附近的存儲單元產(chǎn)生干擾,過度讀取最終會導(dǎo)致存儲單元失去電荷丟失存儲的數(shù)據(jù)。

2. 長期數(shù)據(jù)保留:存儲在 NAND flash中的數(shù)據(jù)會隨著時間的推移而損壞(即使不使用)。

3. 高溫干擾:高溫可能會導(dǎo)致電荷逃逸。隨著溫度的升高,數(shù)據(jù)損壞的速度會迅速增加。

4. 電磁干擾:電磁干擾可能會導(dǎo)致電荷不穩(wěn)定。

Bit Flip 判斷方法

我們知道Nand Flash 為了防止Bit Flip設(shè)計了ECC算法進行糾正位反轉(zhuǎn)數(shù)據(jù),我們也可通過ECC來判斷Nand Flash是否產(chǎn)生了Bit Flip;

模擬page size 為2K ECC 能力為8 byte 的 ecc 分布 Layout

43526340-0177-11ed-ba43-dac502259ad0.png

2048-byte page, 8-bit ECC, 8-bit NAND Flash

通過Layout 可以發(fā)現(xiàn)ECC 其實和OOB區(qū)域是Nand Flash 存儲的一部分,Bit Flip 產(chǎn)生的隨機性同樣也會影響 ECC數(shù)據(jù)和OOB 數(shù)據(jù);

文件系統(tǒng)

這里要特殊說明下文件系統(tǒng), 文件系統(tǒng)的問題可以分為兩種:

1.由于異常掉電導(dǎo)致數(shù)據(jù)寫入未完成,或文件處理邏輯未完成產(chǎn)生的系統(tǒng)性校驗錯誤;

2.文件系統(tǒng)數(shù)據(jù)存儲格式完全依賴于文件系統(tǒng)類型, 同時讀寫分區(qū)的頻繁讀寫, 空間占用大也導(dǎo)致位反轉(zhuǎn)在文件系統(tǒng)區(qū)域概率大大增加;

分析方法

Nand Flash 的Meta Data數(shù)據(jù)能直觀反應(yīng)問題發(fā)生的原因,通過Dump Nand Flash數(shù)據(jù)可以快速排除存儲數(shù)據(jù)本身是否異常;

1.enable ECC dump Nand Flash數(shù)據(jù)就可以獲取當(dāng)前ECC值;

2.使用相同固件在另一塊Nand Flash 中操作步驟1 獲取正常的Meta Data;

3.通過對比不同Nand Flash相同數(shù)據(jù)的ECC 值,可以幫助我們確定是否發(fā)生過位反轉(zhuǎn);

而文件系統(tǒng)需要我們對文件系統(tǒng)機制有一定的了解進而分析異常原因;

Bit Flip 解決方法

多分區(qū),多冗余的方法也同樣可以解決Bit Flip 問題;

只讀鏡像

只讀鏡像分區(qū)可以依賴通用的錯誤處理來解決異常產(chǎn)生后的行為,這樣可以做到處理行為統(tǒng)一;

文件系統(tǒng)

如果有安全考慮的情況下只讀文件系統(tǒng)可以依賴dm-verity功能進行異常檢查, 由于文件系統(tǒng)的復(fù)雜性針對讀寫分區(qū)的異常檢測點需要我們從概率性和必要性進行考慮異常處理的合理性;

還有一種Nand Flash 處于不穩(wěn)定狀態(tài)的情況存在, 這種情況暫時沒有好的解決方案, 在重新燒錄后表現(xiàn)良好使用一段時間后產(chǎn)生大量Bit Flip 也無法通過檢測機制標(biāo)記成壞塊,對特征值(0x55 0xaa)驗證表現(xiàn)正常;

如果懷疑是這種問題可以創(chuàng)建由隨機數(shù)組成的文件對問題區(qū)域進行寫入和讀取驗證, 同時也可加上低溫環(huán)境加大問題復(fù)現(xiàn)幾率;

DDR Bit Flip

還有一種位反轉(zhuǎn)在DDR中產(chǎn)生, 這種情況下產(chǎn)生的異常結(jié)果與Nand Flash Bit Flip基本一致, 區(qū)別在于Nand Flash ECC糾正范圍內(nèi)可保證數(shù)據(jù)的完整性,而 DDR Bit Flip 會直接改變程序邏輯及運行結(jié)果從而產(chǎn)生各種不可預(yù)測的異常情況;

DDR 分析前我們已經(jīng)通過啟動流程定位啟動階段,排除了是由于Nand Flash數(shù)據(jù)導(dǎo)致的異常,所以我們需要對DDR 進行診斷是否發(fā)生異常。在系統(tǒng)側(cè)可以依賴內(nèi)存自我檢測方式Slub Debug、KASAN等進行檢測,但啟動階段會在各個階段遇到DDR Bit Flip無法依賴于系統(tǒng)側(cè)同時系統(tǒng)側(cè)診斷會受到內(nèi)存分配Layout限制無法全局診斷;

SBL 是很多平臺固件加載的第一啟動鏡像,在SBl運行階段大部分內(nèi)存以物理內(nèi)存方式直接訪問,這樣我們可以利用這一性質(zhì)進行內(nèi)存診斷,回讀校驗可以幫助我們快速定位問題點;

導(dǎo)致DDR Bit Flip原因有哪些?

DDR 本身損壞導(dǎo)致Bit Flip的情況非常多這源于DDR 設(shè)計的復(fù)雜性, 能夠通過回讀校驗直接檢測出來的我們都可歸于DDR 本身問題

舉兩個特殊又比較常見的例子進行說明:

Margin問題

Magin 問題通常都是時序問題,問題的來源可能是設(shè)計或者材料上的缺陷導(dǎo)致;

DDR 的0和1是由基本電路控制門電路最終達到標(biāo)準(zhǔn)的"0","1", 如下圖所示當(dāng)在T1時間內(nèi)無法達到電壓閾值H1或者L1門電路將會切到另一端也就是Margin 導(dǎo)致的Bit Flip;

43722dec-0177-11ed-ba43-dac502259ad0.png

Row Hammere

ROW HAMMER 特性,指DDR 內(nèi)存單元之間電子的互相影響,在足夠多臨近行列的訪問次數(shù)后讓某個單元的值從1變成0現(xiàn)象。

DDR 會定時刷新ceil電荷,但是每次對ceil讀寫的時候,會導(dǎo)致臨近的ceil電荷流失,如果針對特定ceil 進行高頻讀寫,那么會出現(xiàn)在刷新時間到達前,出現(xiàn)bitflip問題 。導(dǎo)致程序運行異常

Kernel crash

Kernel Crash的分析是一個老生常談的問題,本文從crash開始 通過啟動流程,Nand Flash,DDR逐一排除最后又回到crash 這里,Kernel 的分析方法與硬件設(shè)計和實際問題有關(guān),所以本文不做專項介紹;

小結(jié)

本文只是工作經(jīng)驗的總結(jié)并無太多細節(jié)展示,希望通過這種從宏觀到微觀剖析的方法幫助大家找到解決問題的思路,分析的方法有很多甚至法律上的“有罪論”、“無罪論”也可以幫助我們梳理當(dāng)前的問題;

原文標(biāo)題:mcp內(nèi)核穩(wěn)定性問題定位思路與方法

文章出處:【微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

審核編輯:彭靜

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 內(nèi)存
    +關(guān)注

    關(guān)注

    8

    文章

    2903

    瀏覽量

    73547
  • 硬件
    +關(guān)注

    關(guān)注

    11

    文章

    3113

    瀏覽量

    65855
  • Kernel
    +關(guān)注

    關(guān)注

    0

    文章

    48

    瀏覽量

    11094
收藏 人收藏

    評論

    相關(guān)推薦

    Linux kernel內(nèi)存管理模塊結(jié)構(gòu)分析

    基于上面章節(jié)的需求,Linux kernel從虛擬內(nèi)存(VM)、DMA mapping以及DMA buffer sharing三個角度,對內(nèi)存進行管理.
    發(fā)表于 09-19 11:55 ?1670次閱讀
    Linux <b class='flag-5'>kernel</b>內(nèi)存管理模塊結(jié)構(gòu)<b class='flag-5'>分析</b>

    iOS KVO crash 自修復(fù)技術(shù)實現(xiàn)與原理解析

    摘要: 【前言】KVO API設(shè)計非常不合理,于是有很多的KVO三方庫,比如 KVOController 用更優(yōu)的API來規(guī)避這些crash,但是侵入性比較大,必須編碼規(guī)范來約束所有人都要使用該方式
    發(fā)表于 02-08 12:30

    在手機上crash時獲取崩潰日志的方法

    通過dSYM文件定位分析crash
    發(fā)表于 05-20 09:18

    Linux Kernel Panic的產(chǎn)生的原因?

    原始的紙筆工具了。 如果kernel dump信息既沒有在/var/log/message里,也沒有在屏幕上,那么嘗試下面的方法來獲?。ó?dāng)然是在還沒有死機的情況下): 如果在圖形界面,切換到終端界面
    發(fā)表于 06-15 06:24

    Linux Kernel核心中文手冊

    Linux Kernel核心中文手冊:Hardware Basic( 硬件基礎(chǔ)知識) 一個操作系統(tǒng)必須和作為它的基礎(chǔ)的硬件系統(tǒng)緊密配合。操作系統(tǒng)需要使用一些只有硬件才能提供的功能。為了
    發(fā)表于 12-08 10:15 ?39次下載
    Linux <b class='flag-5'>Kernel</b>核心中文手冊

    μClinux-kernel-2.6芯片級移植分析與實現(xiàn)

    本文介紹并分析了將基于最新一代Linux 內(nèi)核kernel-2.6 的μClinux-kernel-2.6,移植到尚未被具體支持的處理器芯片Philips-LPC2294 的全過程。給出了2.6 版本內(nèi)核向具體處理器的芯片級移
    發(fā)表于 06-16 09:22 ?13次下載

    T-Kernel在Blackfin處理器上的移植分析

    T-Kernel 是日本T-Engine 組織推出的開源免費的嵌入式實時操作系統(tǒng)(RTOS),以其強實時小體積內(nèi)核著稱。本文針對T-Kernel 在 Blackfin 處理器(BF533)上的移植過程進行了分析,給出了
    發(fā)表于 09-09 16:03 ?23次下載

    T-Kernel對應(yīng)新硬件的實施指南

    實時操作系統(tǒng)T-Kernel的源代碼已在T-Engine Forum開放,它在嵌入式系統(tǒng)中的應(yīng)用也逐漸增多。本文檔總結(jié)了在新硬件中實施T-Kernel時必須探討的事項以及實施要點等,目的是使那些對RTOS并不
    發(fā)表于 04-05 23:22 ?15次下載

    iOS中Crash文件崩潰捕獲分析及符號化思路

    最近在做 Crash 分析方面的工作,發(fā)現(xiàn) iOS 的崩潰捕獲和堆棧符號化雖然已經(jīng)有很多資料可以參考,但是沒有比較完善的成套解決方案,導(dǎo)致操作起來還是要踩很多坑,耽誤了很多時間。所以想做一個總結(jié)
    發(fā)表于 09-25 10:36 ?0次下載
    iOS中<b class='flag-5'>Crash</b>文件崩潰捕獲<b class='flag-5'>分析</b>及符號化思路

    crash工具分析Linux內(nèi)核死鎖的一次實戰(zhàn)分享

    內(nèi)核死鎖問題一般是讀寫鎖(rw_semaphore)和互斥鎖(mutex)引起的,本文主要講如何通過ramdump+crash工具來分析這類死鎖問題。
    的頭像 發(fā)表于 03-17 09:27 ?1.5w次閱讀
    用<b class='flag-5'>crash</b>工具<b class='flag-5'>分析</b>Linux內(nèi)核死鎖的一次實戰(zhàn)分享

    使用Trace View對對Kernel進行性能仿真分析

    Kernel進行性能分析需要對其進行仿真,同時還要用到Vitis Analyzer。為便于說明,我們以一個簡單的Vitis工程為例。這個工程中有兩個kernel,相應(yīng)的代碼如下圖所示
    的頭像 發(fā)表于 03-15 15:30 ?1869次閱讀

    kernel panic流程分析

    我們在項目開發(fā)過程中,很多時候會出現(xiàn)由于某種原因經(jīng)常會導(dǎo)致手機系統(tǒng)死機重啟的情況(重啟分Android重啟跟kernel重啟,而我們這里只討論kernel重啟也就是 kernel panic 的情況
    的頭像 發(fā)表于 01-19 16:14 ?911次閱讀
    <b class='flag-5'>kernel</b> panic流程<b class='flag-5'>分析</b>

    MongoDB索引操作導(dǎo)致Crash的問題及其解決辦法

    近日,朋友遇到一個 MongoDB 實例 Crash 的問題,找到我?guī)兔σ黄?b class='flag-5'>分析原因,事情經(jīng)過以及分析過程如下,可供學(xué)習(xí)。
    的頭像 發(fā)表于 06-20 09:51 ?646次閱讀
    MongoDB索引操作導(dǎo)致<b class='flag-5'>Crash</b>的問題及其解決辦法

    MongoDB 實例 Crash 的故障現(xiàn)象問題

    ? 1故障現(xiàn)象 近日,朋友遇到一個 MongoDB 實例 Crash 的問題,找到我?guī)兔σ黄?b class='flag-5'>分析原因,事情經(jīng)過以及分析過程如下,可供學(xué)習(xí)。 操作過程 運維人員在優(yōu)化慢查詢時針對性創(chuàng)建了一個索引,語句
    的頭像 發(fā)表于 06-29 11:24 ?365次閱讀
    MongoDB 實例 <b class='flag-5'>Crash</b> 的故障現(xiàn)象問題

    kernel日志寫入logd介紹

    kernel日志寫入logd介紹 通過logcat命令獲取kernel日志比較特殊,故作為一個例子進行梳理。 2.3.1 整體流程 2.3.2 命令打印kernel日志 通過logcat -b
    的頭像 發(fā)表于 11-23 17:11 ?484次閱讀
    <b class='flag-5'>kernel</b>日志寫入logd介紹