精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

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

3天內不再提示

Kernel Crash的分析方法與硬件設計

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

簡介

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

啟動流程初判斷

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

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

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

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

Nand Flash排查

針對nand flash的分析要先了解其構造;

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

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

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

Nand Flash 存儲結構

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

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

關于oob具體用途,總結起來有:

1.標記是否是壞快

2.存儲ECC數據

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

Nand Flash 結構

壞塊

為什么會出現壞塊?

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

壞塊的分類

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

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

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

壞塊如何檢測

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

壞塊的影響性

判斷壞塊并不是技術難點,問題是在于當產生壞塊時系統穩定性如何去保障,這里就涉及到項目前期對整體穩定性設計;

根據固件格式大致可以分為三種:只讀鏡像,只讀文件系統和數據分區

1.只讀鏡像

這里只讀鏡像在固件中SBL ,LK,Boot.img 等等鏡像文件, 當鏡像存儲區域由于某種異常產生壞塊就會破壞數據的完整性;

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

2.只讀文件系統

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

3.數據分區

數據分區基本操作就是寫入和擦除,所以當壞塊產生時影響的是在分區中存儲的數據;

數據存儲根據使用功能的不同丟失的影響性也存在較大差異,文件系統中文件數據丟失表現為文件數據無法訪問或者文件不存在訪問失敗;但當重要配置文件丟失, 證書文件,加密裸數據丟失同樣會導致系統崩潰無法正常使用;

預防性設計

萬幸的是使用過程中產生連續三個壞塊的概率極低,這就給我們機會針對壞塊預防性設計;

那我們如何去解決這個問題呢?

了解壞塊的產生和影響性,可以知道想要規避壞塊需要我們在系統設計初就要考慮,在設備使用過程中有壞塊產生時如何保證系統的穩定性;

針對產生的影響性加強系統穩定性設計:

1.只讀鏡像&只讀文件系統

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

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

2種設計可以大大增加系統整體的穩定性,不過多分區設計要注意鄰區干擾要適當的分開;

2.數據分區

根據存儲數據的必要性可以分為重要分區和普通分區;

多分區設計也適用于重要分區 通過多個分區保存重要文件和數據可以避免數據缺失而引發的問題;

分區文件丟失通過備份分區恢復文件;

分區損壞先格式化問題分區后在通過備份分區恢復文件;

由于空間限制重要文件和數據要與普通分區

普通分區由于壞塊導致的異常完全可以通過格式化進行恢復;

Nand Flash Bit Flip

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

什么是Bit Flip?

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

Bit Flip 產生的原因?

借鑒業內總結產生Bit Flip原因有如下幾種:

1.漂移效應(Drifting Effects)

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

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

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

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

此效應是,對一個頁進行數據讀取操作,卻使得對應的某個位的數據,產生了永久性的變化,即Nand Flash上的該位的值變了。

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

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

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

3. 高溫干擾:高溫可能會導致電荷逃逸。隨著溫度的升高,數據損壞的速度會迅速增加。

4. 電磁干擾:電磁干擾可能會導致電荷不穩定。

Bit Flip 判斷方法

我們知道Nand Flash 為了防止Bit Flip設計了ECC算法進行糾正位反轉數據,我們也可通過ECC來判斷Nand Flash是否產生了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 可以發現ECC 其實和OOB區域是Nand Flash 存儲的一部分,Bit Flip 產生的隨機性同樣也會影響 ECC數據和OOB 數據;

文件系統

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

1.由于異常掉電導致數據寫入未完成,或文件處理邏輯未完成產生的系統性校驗錯誤;

2.文件系統數據存儲格式完全依賴于文件系統類型, 同時讀寫分區的頻繁讀寫, 空間占用大也導致位反轉在文件系統區域概率大大增加;

分析方法

Nand Flash 的Meta Data數據能直觀反應問題發生的原因,通過Dump Nand Flash數據可以快速排除存儲數據本身是否異常;

1.enable ECC dump Nand Flash數據就可以獲取當前ECC值;

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

3.通過對比不同Nand Flash相同數據的ECC 值,可以幫助我們確定是否發生過位反轉;

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

Bit Flip 解決方法

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

只讀鏡像

只讀鏡像分區可以依賴通用的錯誤處理來解決異常產生后的行為,這樣可以做到處理行為統一;

文件系統

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

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

如果懷疑是這種問題可以創建由隨機數組成的文件對問題區域進行寫入和讀取驗證, 同時也可加上低溫環境加大問題復現幾率;

DDR Bit Flip

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

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

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

導致DDR Bit Flip原因有哪些?

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

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

Margin問題

Magin 問題通常都是時序問題,問題的來源可能是設計或者材料上的缺陷導致;

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

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

Row Hammere

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

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

Kernel crash

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

小結

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

原文標題:mcp內核穩定性問題定位思路與方法

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

審核編輯:彭靜

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 內存
    +關注

    關注

    8

    文章

    3002

    瀏覽量

    73884
  • 硬件
    +關注

    關注

    11

    文章

    3252

    瀏覽量

    66114
  • Kernel
    +關注

    關注

    0

    文章

    48

    瀏覽量

    11138
收藏 人收藏

    評論

    相關推薦

    Linux kernel內存管理模塊結構分析

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

    iOS KVO crash 自修復技術實現與原理解析

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

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

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

    Linux Kernel Panic的產生的原因?

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

    Linux Kernel核心中文手冊

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

    μClinux-kernel-2.6芯片級移植分析與實現

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

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

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

    T-Kernel對應新硬件的實施指南

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

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

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

    crash工具分析Linux內核死鎖的一次實戰分享

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

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

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

    kernel panic流程分析

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

    MongoDB索引操作導致Crash的問題及其解決辦法

    近日,朋友遇到一個 MongoDB 實例 Crash 的問題,找到我幫忙一起分析原因,事情經過以及分析過程如下,可供學習。
    的頭像 發表于 06-20 09:51 ?740次閱讀
    MongoDB索引操作導致<b class='flag-5'>Crash</b>的問題及其解決辦法

    MongoDB 實例 Crash 的故障現象問題

    ? 1故障現象 近日,朋友遇到一個 MongoDB 實例 Crash 的問題,找到我幫忙一起分析原因,事情經過以及分析過程如下,可供學習。 操作過程 運維人員在優化慢查詢時針對性創建了一個索引,語句
    的頭像 發表于 06-29 11:24 ?417次閱讀
    MongoDB 實例 <b class='flag-5'>Crash</b> 的故障現象問題

    kernel日志寫入logd介紹

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