沒想到上次的Power就寫了滿滿一篇，趕快接續下去，這次是最後一篇了。
https://www.intel.com/content/dam/support/us/en/documents/server-products/SEL_TroubleshootingGuide.pdf

4. Fan sensor log

風扇壞掉的部分就沒什麼好說，這邊就風扇提兩個重點

• System Fan:
  系統上的風扇，有時會覺得好像也沒在幹嘛就轉的非常快，常常會有使用者提出這樣的質疑。此時可以先簡單的確認一下系統風扇的總數與主機spec是否一致，數量不同的話有可能是BMC在識別主機時出了什麼差錯，導致某些風扇轉速為零(不存在此主機的風扇)或是轉速異常的快。也可以準備好你主機上的相關HW清單與BMC sensor清單，請廠商幫你確認目前的轉速是否正常。

• PSU fan:
  PSU也有風扇，有時上頭還有會PSU風扇的方向性，這也是個可以小小留意下的地方。

5. Temperature sensor log

溫度的Sensor想必是大家最熟的，這裡我覺得最重要的就是環境溫度的sensor log，通常都是位於主機的Front panel面板上。有些廠商叫Inlet或是就直接叫FP。

由於各家廠商的各台主機對於這個sensor都有做詳細的測試才訂出他們認為的上下限，因此看到inlet/FP sensor log時，不可不慎，主機上很多零件的異常都將和這個sensor習習相關。

6. UPI log

UPI是指主機板上CPU之間互相交換資料的通道。有時會看到零星的correctable error，不影響穩定性的情況下通常可以觀察看看發生的頻率。

但是如果已經有大量的correctable error or uncorrectable的話，建議需要檢查一下有沒有發生在特定的CPU，將CPU的接點與對應的CPU socket做仔細的檢查。也可以將CPU交換位置並觀察log，或者是更換主機板。

7. Memory Error log

這個項目也是大家滿常見到的，基本上uncorrectable memory error比較不需要討論，換就對了。Correctable memory error就比較依賴使用者自己與廠商間的溝通。由於correctable memory error本身的呈現，背後也有一些BIOS計算方式的干涉，會建議使用者依自身的成本與穩定度的考量和廠商討論後再下更換的決定。

另外，雖然文件中沒有提到，隨著記憶體除錯與糾正技術的進步，DDR4的記憶體已經支援PPR(Post Package Repair)這樣的技術，利用記憶體上備用的位址來替代出錯的部分。

8. PCI Error log

這個error log應該是僅次於memory error的大宗，correctable error的計算和memory一樣同時都會受到BIOS的干涉，零星的correctable error在不影響效能的前提下都可以觀察一下。倒是uncorrectable error發生時，除了更換PCI裝置，可能還需要考慮一下像是裝置過熱或者FW出錯的情況，避免做無謂的重複更換。

9. BIOS POST code

POST Code對使用者的作用是在提供開機過程卡在BIOS時，使用者能夠從旁了解可能卡住的原因然後視情況自己先行排除。

常見的使用者能夠排除的情況像：

1. Memory Population Error - 需要重新檢查記憶體的安裝位置或是型號是否不符合要求
2. Memory failed test/initialization- 重新檢查記憶體型號或是沒插好
3. Processor Model Mismatch - CPU有混插的情形

10. Watchdog timer log

常見的如：
BIOS FRB2，POST卡住時，BIOS將主機自行重開的計時器對應的log。通常會配合之前的BIOS POST code做檢查。

BMC watchdog timer(mgmt subsystem health)，BMC的FW重置或是CPU reset的timer對應的log。這個可能就需要接BMC debug console才能得到最完整的說明。

11. OS Records

• Windows的部分，從2003R2開始導入IPMI的driver，因此具備在開機/關機/BSOD的情況下寫入SEL的能力。這也可以作為判斷主機狀態的重要log。

• Linux的部分，可以透過OpenIPMI driver在kernel panic的情況下寫入SEL。

心得與總結

寫到這裡真的是很意外最後竟然花了三篇才完成，其實中間還跳過了一些之前介紹過因此就不想再提的IERR，還有ME的部分等。有些log本身就是troubleshooting的本體，而有的log則是用來做客觀的判斷或是與客人所說的對照。就像是電源的部分，你能深入的將發生這些log的詳細時機搞清楚，越能幫助你在除錯時找到更多的線索，同時釐清那些溝通上的問題。在一些複雜的情況，廠商的工程師也不見得能對這些log發生的時機解說的這麼清楚，有時依照客人所說的步驟，並提出比對log的請求也是一個協助雙方討論下去的好方法。