上周五下午我連續(xù)接了三通技術(shù)求助。第一通來(lái)自機(jī)房值班同事說(shuō)一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器在系統(tǒng)日志里反復(fù)出現(xiàn)uncorr. ecc關(guān)鍵詞錯(cuò)誤計(jì)數(shù)顯示為 2。第二通是芯片驗(yàn)證組的說(shuō) MBIST 測(cè)試?yán)锏?ECC 覆蓋率卡在 92% 提不上去。第三通來(lái)自做 SAP 財(cái)務(wù)實(shí)施的顧問(wèn)問(wèn)我年底結(jié)賬時(shí) CO88 一直報(bào)錯(cuò)內(nèi)部訂單結(jié)不掉。三通電話、三個(gè)行業(yè)問(wèn)題里卻都有同一個(gè)縮寫(xiě)ECC。掛掉電話之后我就在想ECC 這三個(gè)字母在運(yùn)維、半導(dǎo)體、企業(yè)管理軟件三個(gè)圈子里代表的其實(shí)是完全不同的三套技術(shù)體系。很多人只熟悉其中一個(gè)遇到另外兩個(gè)就發(fā)懵。所以這篇文章我打算把三條線都拆開(kāi)講一遍把我實(shí)際處理過(guò)的流程和踩過(guò)的坑寫(xiě)出來(lái)給同樣被ECC困擾過(guò)的人一個(gè)參考。1. 機(jī)房里的ECC從uncorr. ecc報(bào)警到內(nèi)存條更換的完整鏈路1.1 糾錯(cuò)碼怎么工作64位數(shù)據(jù)為什么變成了72位ECC 的全稱是 Error Correcting Code糾錯(cuò)碼。要理解它先要理解一個(gè)更簡(jiǎn)單的概念奇偶校驗(yàn)。奇偶校驗(yàn)就是一個(gè)數(shù)據(jù)塊里數(shù) 1 的個(gè)數(shù)是奇數(shù)還是偶數(shù)用一位額外的 bit 記錄這個(gè)狀態(tài)讀數(shù)據(jù)時(shí)再數(shù)一次。有一位出錯(cuò)立刻能發(fā)現(xiàn)不對(duì)但只能發(fā)現(xiàn)不能定位所以沒(méi)法修。而且如果有兩位同時(shí)出錯(cuò)奇偶校驗(yàn)直接失靈它還以為數(shù)據(jù)是對(duì)的。漢明碼是 ECC 的基礎(chǔ)思路它把數(shù)據(jù)位按照一定規(guī)則放進(jìn)多個(gè)互相交疊的校驗(yàn)組里每個(gè)校驗(yàn)位管一組。數(shù)據(jù)出錯(cuò)時(shí)多個(gè)校驗(yàn)位會(huì)同時(shí)報(bào)警根據(jù)哪幾個(gè)校驗(yàn)位報(bào)錯(cuò)了這個(gè)組合反推就能知道是哪一位數(shù)據(jù)出了問(wèn)題。這就像幾個(gè)保安分別值守不同的區(qū)域某個(gè)區(qū)域出事的時(shí)候能看到該區(qū)域的保安同時(shí)報(bào)警于是就能定位到具體位置。具體到內(nèi)存條層面一條支持 ECC 的 DDR 通道數(shù)據(jù)總線是 64 位再加 8 位校驗(yàn)位總共 72 位。就是這多出來(lái)的 8 位讓內(nèi)存能夠在讀取時(shí)發(fā)現(xiàn)并修正 1 個(gè)比特位的錯(cuò)誤同時(shí)檢測(cè)出 2 個(gè)比特位的錯(cuò)誤。這就是常說(shuō)的SECDEDSingle Error Correct, Double Error Detect。消費(fèi)級(jí)電腦基本不配這個(gè)服務(wù)器和工作站基本都會(huì)配因?yàn)殚L(zhǎng)期運(yùn)行和數(shù)據(jù)完整性是剛需。但我得先提醒一句話ECC 不是備份。它防的是單比特翻轉(zhuǎn)這種小概率事件比如宇宙射線擊中內(nèi)存顆粒、供電噪聲干擾。一旦出現(xiàn)大面積顆粒損壞或線路虛焊ECC 也會(huì)力不從心這就引出后面的不可糾正錯(cuò)誤。1.2 uncorr. ecc 顯示2可糾正與不可糾正到底差在哪顯示2這種說(shuō)法其實(shí)來(lái)自服務(wù)器 BMC、系統(tǒng)日志或者 EDAC 工具里的錯(cuò)誤計(jì)數(shù)。在 Linux 上通常能看到兩類計(jì)數(shù)器CECorrected Error可糾正錯(cuò)誤和UEUncorrected Error不可糾正錯(cuò)誤。CE 出現(xiàn)時(shí)ECC 自己就把 1 位比特錯(cuò)誤糾正了業(yè)務(wù)層面無(wú)感知但計(jì)數(shù)會(huì)漲。UE 出現(xiàn)時(shí)說(shuō)明出現(xiàn)了 ECC 處理不了的錯(cuò)誤?？赡苁?2 bit 同時(shí)翻轉(zhuǎn)也可能是某個(gè)內(nèi)存顆粒徹底壞了。這種情況下系統(tǒng)無(wú)法保證數(shù)據(jù)正確性嚴(yán)重時(shí)直接觸發(fā) MCEMachine Check Exception導(dǎo)致機(jī)器重啟甚至內(nèi)核 panic。有一次我處理過(guò)一臺(tái)運(yùn)行三年多的數(shù)據(jù)庫(kù)服務(wù)器日志里出現(xiàn) 1 次 UE當(dāng)時(shí)沒(méi)太在意想著先觀察。結(jié)果一個(gè)月不到同一根內(nèi)存條上的 UE 計(jì)數(shù)漲到了兩位數(shù)期間還發(fā)生了兩次數(shù)據(jù)庫(kù)進(jìn)程被異常殺掉的故障。所以我現(xiàn)在只要看到 UE 出現(xiàn)在日志里第一反應(yīng)就是安排維護(hù)窗口。只要有條件能關(guān)就關(guān)、能換就換千萬(wàn)不要賭它只是偶發(fā)。1.3 排查鏈路從MCE日志、EDAC計(jì)數(shù)到物理插槽定位排查一條完整鏈路Linux 下第一步看內(nèi)核日志dmesg | grep -i -E edac|mce|memory error也可以看 EDAC 的計(jì)數(shù)節(jié)點(diǎn)edac-util --status cat /sys/devices/system/edac/mc/mc0/ce_count cat /sys/devices/system/edac/mc/mc0/ue_count裝了 rasdaemon 的情況ras-mc-ctl --error-count ras-mc-ctl --summary看 MCE 記錄mcelog --client解析出來(lái)的信息里最關(guān)鍵的字段是 Memory Controller、Bank Group、Bank、Row、Column。有了這些地址信息再配合主板手冊(cè)的內(nèi)存插槽映射表才能判斷是哪個(gè) DIMM 槽位。不過(guò)說(shuō)實(shí)話物理定位很多時(shí)候沒(méi)那么精確。我的實(shí)踐經(jīng)驗(yàn)是先在 BIOS 里看 memory info同時(shí)用拔一半內(nèi)存跑內(nèi)存壓力測(cè)試的二分法快速縮小范圍。跑 MemTest86 或者 Linux 下的 memtester每個(gè)內(nèi)存槽輪流測(cè)。如果服務(wù)器支持熱插拔內(nèi)存就按檢查結(jié)果直接替換不支持就按維護(hù)窗口停機(jī)替換。分享一個(gè)真實(shí)案例之前有臺(tái) Dell R740 報(bào) UEdmesg 輸出指向 Channel 1 DIMM B 地址區(qū)域。我直接把 DIMM A 和 DIMM B 對(duì)調(diào)再跑一次內(nèi)存壓力測(cè)試報(bào)警位置跟著 DIMM 走了基本鎖定是某一根條子替換后問(wèn)題消失。這個(gè)對(duì)調(diào)法在插槽映射表格不夠清楚時(shí)特別好用能省下不少查手冊(cè)的時(shí)間。1.4 CE與UE的處理策略我的服務(wù)器運(yùn)維經(jīng)驗(yàn)CE 要不要立刻處理我的策略是偶爾一次 CE 可以記錄觀察但如果 CE 在一個(gè)小時(shí)內(nèi)連續(xù)出現(xiàn)多次說(shuō)明顆?？赡芤呀?jīng)有物理退化趨勢(shì)。正常的 ECC 內(nèi)存CE 是很低頻的一年下來(lái)可能就是個(gè)位數(shù)。如果 CE 計(jì)數(shù)每個(gè)月都在明顯增長(zhǎng)就把它當(dāng) UE 的前兆處理提前備新內(nèi)存、提前約維護(hù)窗口。另一個(gè)容易被忽略的因素是溫度。內(nèi)存顆粒過(guò)熱會(huì)大幅增加軟錯(cuò)誤率。我見(jiàn)過(guò)一臺(tái)機(jī)器換了新內(nèi)存后還是頻繁報(bào) CE排查半天發(fā)現(xiàn)是內(nèi)存上方風(fēng)道被灰塵堵了溫度長(zhǎng)期在 90 度附近。清灰之后 CE 計(jì)數(shù)再?zèng)]漲過(guò)。所以報(bào)錯(cuò)后別急著只會(huì)換內(nèi)存先看溫度、看電壓、看頻率。還要注意XMP/EXPO 這類內(nèi)存超頻配置在服務(wù)器環(huán)境里能不開(kāi)就別開(kāi)。很多內(nèi)存不穩(wěn)定的報(bào)錯(cuò)其實(shí)是在一個(gè)并不保證穩(wěn)定的頻率下跑出來(lái)的。先把內(nèi)存降到 JEDEC 標(biāo)準(zhǔn)頻率再觀察問(wèn)題往往就消失了。這個(gè)經(jīng)驗(yàn)在自建實(shí)驗(yàn)室服務(wù)器上特別常見(jiàn)。2. 芯片出廠前的那道關(guān)MBIST ECC與測(cè)試覆蓋率難題2.1 MBIST為什么存在芯片測(cè)試的性價(jià)比問(wèn)題MBIST 全稱 Memory Built-In Self-Test存儲(chǔ)器內(nèi)建自測(cè)試。芯片越做越大存儲(chǔ)器SRAM、寄存器堆、緩存占整個(gè) SoC 面積的比例越來(lái)越高很多芯片里 SRAM 能占到 40% 到 60% 以上。如果所有存儲(chǔ)單元測(cè)試都靠外部 ATE自動(dòng)測(cè)試設(shè)備來(lái)做測(cè)試時(shí)間會(huì)非常長(zhǎng)測(cè)試向量極其龐大成本直接失控。于是行業(yè)里想出一個(gè)辦法在芯片內(nèi)部放一個(gè)自檢程序用硬件狀態(tài)機(jī)實(shí)現(xiàn)的測(cè)試控制器。它上電后自己產(chǎn)生地址、數(shù)據(jù)、讀寫(xiě)控制信號(hào)對(duì)每一塊存儲(chǔ)器執(zhí)行標(biāo)準(zhǔn)測(cè)試算法然后把結(jié)果保存在寄存器里外部通過(guò) JTAG 或調(diào)試接口讀取結(jié)果。這就是 MBIST。打個(gè)比方ATE 測(cè)試像是每輛車都開(kāi)到檢測(cè)站做檢測(cè)MBIST 則是每輛車出廠前自己跑一遍內(nèi)置自檢程序檢測(cè)站只讀一個(gè) PASS/FAIL 結(jié)果。2.2 常見(jiàn)故障模型與March算法MBIST的測(cè)試語(yǔ)言MBIST 的測(cè)試算法不是亂寫(xiě)的。芯片制造過(guò)程中存儲(chǔ)單元會(huì)有各種物理缺陷對(duì)應(yīng)不同故障模型SAFStuck-At Fault固定故障某個(gè) cell 永遠(yuǎn)讀出 0 或永遠(yuǎn)讀出 1TFTransition Fault轉(zhuǎn)換故障0→1 或 1→0 轉(zhuǎn)換無(wú)法完成CFCoupling Fault耦合故障一個(gè) cell 的狀態(tài)變化影響了相鄰 cell地址譯碼故障地址線短路或斷路導(dǎo)致訪問(wèn) A 地址時(shí)實(shí)際訪問(wèn)了 B 地址最經(jīng)典的測(cè)試算法是 March 算法族其中March C-是工業(yè)界用得最多的模板之一。它的流程大致是先全寫(xiě) 0然后從低地址往高地址做讀 0、寫(xiě) 1操作再?gòu)母叩刂吠偷刂纷鲎x 1、寫(xiě) 0操作如此反復(fù)幾個(gè) march element最后全讀 0。它能把 SAF、TF、CF 全部覆蓋而且復(fù)雜度只有 O(n)意思是存儲(chǔ)器容量越大測(cè)試時(shí)間線性增長(zhǎng)而不是指數(shù)增長(zhǎng)。除了 March 算法還有棋盤格Checkerboard、走步GALPAT、蝴蝶Butterfly等測(cè)試方式各自針對(duì)不同類型的缺陷更敏感。實(shí)際項(xiàng)目中通常組合使用先用快速 March 算法做全量掃查再用定向算法做診斷。2.3 把ECC放進(jìn)MBIST硬錯(cuò)誤與軟錯(cuò)誤的邊界MBIST ECC 這一塊很多人理解成在 MBIST 里面跑一段 ECC 校驗(yàn)這個(gè)理解太淺了。真正的問(wèn)題在于MBIST 測(cè)試的目標(biāo)是物理缺陷硬錯(cuò)誤但測(cè)試過(guò)程中的軟錯(cuò)誤會(huì)干擾判斷。軟錯(cuò)誤是什么就是存儲(chǔ)單元本身沒(méi)壞但 α 粒子或電磁干擾讓它暫時(shí)翻轉(zhuǎn)了。如果你用普通 MBIST 測(cè)到某個(gè) cell 讀寫(xiě)不一致你沒(méi)法判斷是cell 真的壞了還是測(cè)試瞬間受干擾。如果在 MBIST 里加入 ECC 能力當(dāng)檢查到單比特翻轉(zhuǎn)時(shí)ECC 能糾正它于是可以區(qū)分糾正成功且后續(xù)重復(fù)測(cè)試不再出錯(cuò)大概率是軟錯(cuò)誤糾正失敗或者同一位置反復(fù)報(bào)錯(cuò)就是硬故障。這個(gè)區(qū)分對(duì)良率分析特別重要——把軟錯(cuò)誤當(dāng)硬故障去修會(huì)白白浪費(fèi)冗余資源。另一個(gè)關(guān)鍵點(diǎn)是用 ECC 校驗(yàn)測(cè)試邏輯本身。車規(guī)級(jí)芯片里功能安全標(biāo)準(zhǔn)明確要求存儲(chǔ)器的保護(hù)邏輯包括 ECC也要被測(cè)試覆蓋。如果 ECC 邏輯自己壞了運(yùn)行時(shí)即使內(nèi)存出錯(cuò)它也不會(huì)報(bào)這是很危險(xiǎn)的事。所以在 MBIST 里設(shè)計(jì)專門的測(cè)試模式做錯(cuò)誤注入error injection驗(yàn)證 ECC 電路能否正確檢測(cè)和糾正預(yù)設(shè)錯(cuò)誤模式是必不可少的一步。2.4 冗余修復(fù)與良率ECC和Repair的配合MBIST 測(cè)出壞 cell 之后怎么辦直接報(bào)廢良率太低。所以現(xiàn)代 SoC 都帶冗余修復(fù)機(jī)制在存儲(chǔ)陣列旁邊放額外行或列冗余行/列測(cè)試時(shí)發(fā)現(xiàn)故障 cell通過(guò) eFuse 或激光熔絲把壞行列整個(gè)禁用把備用行列映射進(jìn)去。這個(gè)流程叫Repair。ECC 在這里也有戲份有些壞 cell 是間歇性故障測(cè)試時(shí)有時(shí)好有時(shí)壞一次性很難抓到。通過(guò) ECC 的錯(cuò)誤計(jì)數(shù)輔助可以識(shí)別出哪些區(qū)域錯(cuò)誤率異常高再?zèng)Q定是否啟用冗余修復(fù)。換句話說(shuō)ECC 提供了趨勢(shì)級(jí)的故障證據(jù)而不只是對(duì)/錯(cuò)的 bit。從這個(gè)角度看MBIST ECC 和內(nèi)存子系統(tǒng)的 ECC 本質(zhì)是一回事都是通過(guò)冗余信息實(shí)現(xiàn)對(duì)錯(cuò)誤的感知、糾正和記錄只是應(yīng)用階段不同——一個(gè)在出廠前幫助提升良率一個(gè)在運(yùn)行期保障數(shù)據(jù)安全。3. 財(cái)務(wù)系統(tǒng)里的ECCSAP年結(jié)從余額結(jié)轉(zhuǎn)到訂單結(jié)算3.1 SAP ECC是什么為什么年結(jié)是個(gè)大事先澄清一個(gè)事在這個(gè)語(yǔ)境下ECC 不是 Error Correcting Code而是ERP Central Component。SAP ECC 是 SAP ERP 6.0 這套企業(yè)管理軟件的核心組件承載企業(yè)財(cái)務(wù)、采購(gòu)、銷售、生產(chǎn)、庫(kù)存、人力等核心業(yè)務(wù)。這些年 SAP 在推 S/4HANA但大量企業(yè)還在使用 ECC 體系所以ECC 年結(jié)這個(gè)詞在財(cái)務(wù)顧問(wèn)和企業(yè) IT 運(yùn)維圈子里依然高頻出現(xiàn)。年結(jié)就是年度結(jié)轉(zhuǎn)一年做一次。它的核心邏輯是當(dāng)前年度結(jié)束后把所有損益科目余額歸零并轉(zhuǎn)入留存收益科目把資產(chǎn)負(fù)債表科目的期末余額轉(zhuǎn)為新年度期初余額同時(shí)處理掉所有應(yīng)該在舊年度清掉的未清項(xiàng)目。這個(gè)動(dòng)作在 ECC 里跨了好幾個(gè)模塊FI財(cái)務(wù)會(huì)計(jì)、CO管理會(huì)計(jì)、AM資產(chǎn)管理、MM物料管理、SD銷售分銷。任何一個(gè)模塊沒(méi)處理干凈年結(jié)就過(guò)不去。3.2 年結(jié)步驟拆解FI余額結(jié)轉(zhuǎn)、資產(chǎn)年結(jié)、CO訂單結(jié)算年結(jié)不是一個(gè)事務(wù)代碼的事是一套順序化流程。先說(shuō)FI 余額結(jié)轉(zhuǎn)通常用事務(wù)代碼 FAGLGVTR新總賬或 F.16經(jīng)典總賬。結(jié)轉(zhuǎn)前先要打開(kāi)新會(huì)計(jì)年度做平衡檢查然后執(zhí)行結(jié)轉(zhuǎn)。核心是把 PL 科目余額轉(zhuǎn)入指定留存收益科目同時(shí)把 BS 科目期末余額變成新年度期初余額。再說(shuō)資產(chǎn)年結(jié)事務(wù)代碼 AJAB。執(zhí)行前必須先確認(rèn)本年折舊都已過(guò)賬AFAB資產(chǎn)主數(shù)據(jù)處于正常狀態(tài)不能有未過(guò)賬的資產(chǎn)購(gòu)置或減值發(fā)生。如果折舊沒(méi)跑完AJAB 直接告訴你折舊未完全過(guò)賬。然后是CO 月結(jié)/年結(jié)這是最容易出問(wèn)題的地方。成本中心、內(nèi)部訂單、生產(chǎn)訂單在年底要保證余額清零。常規(guī)流程是用 KSS2 做實(shí)際作業(yè)價(jià)格切割用 KKAO 做作業(yè)價(jià)格重估用 KGI2 計(jì)算在產(chǎn)品WIP用 KO88 結(jié)算內(nèi)部訂單用 CO88 結(jié)算生產(chǎn)訂單所有訂單如果還有未分配成本或未確認(rèn)投入結(jié)算就會(huì)報(bào)錯(cuò)。常見(jiàn)的補(bǔ)救方式是回到源頭把收貨、發(fā)票、費(fèi)用分配補(bǔ)齊讓訂單變成可結(jié)算狀態(tài)然后重新執(zhí)行結(jié)算。MM 模塊要注意年度切換前要把 GR/IR 科目清理干凈做庫(kù)存盤點(diǎn)MI04 錄入盤點(diǎn)結(jié)果MI07 過(guò)賬盤盈虧差異未清的采購(gòu)訂單要么收貨要么取消。SD 側(cè)要檢查未交貨的銷售訂單決定是否順延到新年度處理。3.3 年結(jié)最容易卡的三個(gè)環(huán)節(jié)第一個(gè)坑CO88 報(bào)訂單成本差異未處理。這個(gè)往往是因?yàn)楫?dāng)月實(shí)際成本計(jì)算沒(méi)跑完或者差異金額沒(méi)有調(diào)整到恰當(dāng)科目。解決思路不是繞過(guò)報(bào)錯(cuò)而是回頭跑完 KSS2/KKAO把差異清算后再做結(jié)算。第二個(gè)坑資產(chǎn)年結(jié)報(bào)折舊未完全過(guò)賬。原因是 AFAB 雖然跑了但部分資產(chǎn)因?yàn)檎叟f碼設(shè)置問(wèn)題沒(méi)被選入或者上月折舊有沖銷導(dǎo)致當(dāng)月實(shí)際折舊額不對(duì)。處理方式是檢查資產(chǎn)過(guò)賬日志把遺漏折舊補(bǔ)跑再重新執(zhí)行 AJAB。第三個(gè)坑余額結(jié)轉(zhuǎn)后發(fā)現(xiàn)憑證有問(wèn)題。年結(jié)時(shí)會(huì)生成大量自動(dòng)憑證一旦某個(gè)憑證分配錯(cuò)了科目或金額沖銷很麻煩。所以我建議正式年結(jié)前先在測(cè)試 client 里完整演練一遍確認(rèn)結(jié)轉(zhuǎn)憑證和報(bào)表無(wú)誤后再生產(chǎn)執(zhí)行。別嫌麻煩這個(gè)演練能幫你躲過(guò) 90% 的年結(jié)之夜翻車。3.4 年結(jié)時(shí)間線與演練建議我見(jiàn)過(guò)的靠譜團(tuán)隊(duì)年結(jié)安排大致是這樣的年底前一個(gè)月定方案、定業(yè)務(wù)凍結(jié)窗口、定責(zé)任人年底最后一周發(fā)布凍結(jié)通知停止與舊年度相關(guān)的收貨、發(fā)貨、開(kāi)票、采購(gòu)審批集中處理未清項(xiàng)跨年夜或元旦假期按 FI 余額結(jié)轉(zhuǎn) → CO 訂單結(jié)算 → 資產(chǎn)年結(jié) → 后勤模塊收尾的順序執(zhí)行安排專人盯 SM37 后臺(tái)作業(yè)隊(duì)列新年度第一周驗(yàn)證期初余額、跑平衡檢查、抽查關(guān)鍵報(bào)表經(jīng)驗(yàn)之談年結(jié)做得好不好90% 的功夫在于前置清理。很多人年結(jié)加班到半夜不是因?yàn)榻Y(jié)轉(zhuǎn)本身難而是因?yàn)槠綍r(shí)月結(jié)和清賬沒(méi)做好年底所有問(wèn)題一起爆發(fā)。如果想少加班平時(shí)每個(gè)月就把 CO 訂單結(jié)掉、GR/IR 差異清掉、資產(chǎn)折舊確認(rèn)掉年底自然順暢得多。4. 三套ECC體系下的實(shí)操經(jīng)驗(yàn)與共同底牌4.1 共同經(jīng)驗(yàn)一先看日志再動(dòng)設(shè)備、動(dòng)數(shù)據(jù)無(wú)論是內(nèi)存 ECC、MBIST ECC 還是 SAP 年結(jié)我發(fā)現(xiàn)最容易犯的錯(cuò)誤就是不看日志直接上手。服務(wù)器 UE 報(bào)警上來(lái)就換內(nèi)存結(jié)果可能是溫度問(wèn)題MBIST 覆蓋率低上來(lái)就調(diào)算法參數(shù)結(jié)果可能是測(cè)試頻率太高導(dǎo)致誤判年結(jié)失敗反復(fù)點(diǎn)重跑按鈕結(jié)果底層是一筆憑證沒(méi)清。解決方案都一樣先把日志、計(jì)數(shù)、狀態(tài)表拉出來(lái)看一遍。內(nèi)存看 dmesg、EDAC、MCEMBIST 看 DFT 寄存器的 fail 地址和 fail 計(jì)數(shù)SAP 年結(jié)看 CO88 錯(cuò)誤列表和 COGI、VF04 這類未處理隊(duì)列。日志就是證據(jù)先看證據(jù)再?zèng)Q策。沒(méi)有證據(jù)鏈的排查本質(zhì)上是在碰運(yùn)氣。4.2 共同經(jīng)驗(yàn)二校驗(yàn)邏輯只是兜底治理要前置ECC 糾錯(cuò)能力再?gòu)?qiáng)也只是在錯(cuò)誤發(fā)生之后做補(bǔ)救MBIST 覆蓋率再高也不能把壞 cell 變成好 cell年結(jié)流程再完善也不能替你把平時(shí)該清的賬清掉。很多問(wèn)題的根因都在源頭。芯片設(shè)計(jì)階段如果把 ECC 當(dāng)成后補(bǔ)保護(hù)傘板級(jí)信號(hào)完整性和內(nèi)存顆粒選型不重視運(yùn)行時(shí) ECC 報(bào)警必然頻繁芯片項(xiàng)目如果前期不規(guī)劃 DFT 覆蓋率和 repair 資源量產(chǎn)良率就很難看財(cái)務(wù)團(tuán)隊(duì)如果每個(gè)月不認(rèn)真結(jié)賬年底必然連環(huán)爆。治理動(dòng)作前置永遠(yuǎn)比事后補(bǔ)救省力。4.3 一個(gè)縮寫(xiě)、三套黑話術(shù)語(yǔ)對(duì)照與應(yīng)急速查為了方便在不同領(lǐng)域之間切換我給讀者整理了一張對(duì)照表詞內(nèi)存ECCMBIST ECCSAP ECC全稱Error Correcting CodeError Correcting Code內(nèi)建自測(cè)試語(yǔ)境ERP Central Component出現(xiàn)場(chǎng)景服務(wù)器運(yùn)行期芯片出廠前測(cè)試企業(yè)ERP財(cái)務(wù)年結(jié)核心指標(biāo)CE/UE計(jì)數(shù)故障覆蓋率、修復(fù)率結(jié)轉(zhuǎn)成功/失敗錯(cuò)誤處理糾正、告警、更換修復(fù)、壓制、分析調(diào)整、重跑、重新結(jié)算關(guān)鍵工具dmesg、edac-util、mcelogJTAG、DFT寄存器、eFuseFAGLGVTR、AJAB、CO88、SM37另外提醒一點(diǎn)如果工作中接到一個(gè)只說(shuō)ECC 有問(wèn)題的需求先確認(rèn)對(duì)方在哪個(gè)領(lǐng)域再開(kāi)始排查。方向錯(cuò)了再多的技術(shù)動(dòng)作都是白費(fèi)。最后分享一個(gè)我自己的習(xí)慣不管是處理內(nèi)存報(bào)警、芯片測(cè)試還是 ERP 年結(jié)我都會(huì)先在紙上寫(xiě)清楚三件事——現(xiàn)在有什么異常、數(shù)據(jù)或日志里留下了什么痕跡、我打算動(dòng)哪一步來(lái)改變現(xiàn)狀。三套 ECC 體系雖然完全不同但這個(gè)思路從來(lái)沒(méi)變過(guò)。如果你也能從確認(rèn)現(xiàn)場(chǎng)證據(jù)開(kāi)始而不是一上來(lái)就猜和試很多問(wèn)題根本不會(huì)浪費(fèi)你幾個(gè)小時(shí)甚至一個(gè)通宵。