Ciao~很想用「古代」兩個字來說IPMI command，但實際上現在還是有很多server使用IPMI command在溝通。儘管現在已經是redfish出來之後，大家開始切換user interface之後，每每客人問我有什麼是redfish辦不到的嗎？我就還是會提到 IPMI watchdog這組 commands，它由IPMI command來支援最順。當然，BIOS不僅可以想辦法支援redfish, 也許也可以走PLDM協定...(我就不是太了解，最新的進度到哪裡了？）暫且不管BIOS和BMC之間究竟如何溝通，先跟大家介紹一下server開機的時候為什麼要有Watchdog?
為什麼要有 Watchdog？
在沒有外部監控的情況下，BMC（Baseboard Management Controller）必須能判斷「Host 還活著嗎？」。這在伺服器的開機流程中特別重要——BIOS 可能卡在記憶體測試、也可能卡在 PCIe 初始化、甚至還沒送出第一個 POST code。 如果沒有人「踢狗」，BMC 就該懷疑：Host 出問題了。早期這一切是由 IPMI (Intelligent Platform Management Interface) 定義的。
IPMI 是一套古老但經典的協定，幾乎所有伺服器廠都曾遵守它。 在它的規範裡，Watchdog Timer 是一組可由 BIOS 或 OS 設定的機制。 BMC 端保存著一組暫存器，當主機開機後，BIOS 通過 KCS (Keyboard Controller Style) 介面，發送一組 IPMI 指令，告訴 BMC：
“我打算開機了。請幫我設一個計時器。如果我沒來得及關掉它，就重啟。”
這個概念在 IPMI 規範裡叫作「FRB - Fault Resilient Booting」。FRB 被分成幾個階段，最常見的是 FRB-2，也就是在 BIOS 正在執行 POST（Power-On Self Test）階段時的 watchdog。它的用途很單純： 假設 BIOS 卡在某個初始化環節、無法完成開機，那麼 Watchdog Timer 到期後，BMC 就會自動觸發硬重啟
除此之外，作業系統也能透過 IPMI command Set Watchdog Timer 來指定 timeout 值、要採取的動作（Reset / Power off / Power cycle）、以及啟用狀態。然後它會定期發送 Reset Watchdog Timer 指令給 BMC。當 OS 掛掉、kernel panic 或 driver 卡死時，這些指令就不會再送出，BMC 便會在計時結束後採取動作。
OpenBMC 裡的 Watchdog：一個可觀測的系統服務
OpenBMC 把這個概念重新包裝成一個現代的架構。它不再是寫暫存器、也不再靠特定硬體介面（像 KCS）才能用。 而是成為整個系統裡的一個 D-Bus 服務，名字叫 xyz.openbmc_project.State.Watchdog。
在 BMC 開機時，systemd 會啟動一個名為 phosphor-watchdog 的 daemon。這個服務有幾個關鍵任務：
- 提供 D-Bus 介面，讓任何上層應用（如 IPMI daemon、PLDM responder、Host state manager）都能設定或控制 watchdog。
- 用一個事件驅動的
sdeventplus::Timer來模擬硬體倒數。 - 當 timeout 時，去啟動對應的 systemd unit，例如
phosphor-watchdog-host-reset.service。
這樣的設計讓 watchdog 的管理變得可被觀測、可被測試，也能與 systemd 的事件系統完全整合。
啟動的瞬間：Watchdog 怎麼被建立
當 phosphor-watchdog service 被 systemd 啟動時，它會透過命令列參數來決定行為。例如：
ExecStart=/usr/bin/env phosphor-watchdog \
--service=xyz.openbmc_project.Watchdog \
--path=/xyz/openbmc_project/watchdog/host0 \
--action_target=xyz.openbmc_project.State.Watchdog.Action.HardReset=phosphor-watchdog-host-reset.service \
--action_target=xyz.openbmc_project.State.Watchdog.Action.PowerOff=phosphor-watchdog-host-poweroff.service \
--action_target=xyz.openbmc_project.State.Watchdog.Action.PowerCycle=phosphor-watchdog-host-cycle.service
它建立了一張「當 watchdog 超時時，要執行哪個 systemd 單位」的對照表。
例如：
- 如果設定的超時動作是 HardReset，就執行
phosphor-watchdog-host-reset.service。 - 如果是 PowerOff，就執行
phosphor-watchdog-host-poweroff.service。 - 如果是 PowerCycle，就執行
phosphor-watchdog-host-cycle.service。
這樣設計的好處是：每個動作都可以獨立被 systemd 管理。我們也在這個設計看到一個很巧妙的地方，如果今天你的系統power off的service和大多數人都不同，那你可以把要執行哪一個service填上去就好, 至於那個service要做什麼？怎麼做？就各自去規範。所以要改動作、改超時反應、不用改 watchdog 原始碼，只要修改 service file。
當 Host 啟動時：誰來踢狗？
在開機的早期階段，BIOS 是最先「接手生命」的軟體。它透過 LPC 或 eSPI 通道與 BMC 溝通。 在傳統平台上，BIOS 會透過 IPMI command 來設定或重設 watchdog。 而在支援 PLDM 的新平台上，這個行為被取代成 PLDM over MCTP 的封包。
但不論底層介面怎樣，最終都會變成同一件事：
有一個上層服務呼叫了 BMC 內部的 ResetTimeRemaining()。
在 OpenBMC 裡，這個動作通常由兩種來源觸發：
- BIOS 每送出一個新的 POST code（代表仍在執行中），就觸發一次踢狗。
- BMC 收到 host 發出的
ResetWatchdogTimer命令(不論是IPMI或者PLDM或者其他的方式...)後，在 BMC 端轉為 D-Bus 呼叫。
這兩種方式都會讓 phosphor-watchdog 的倒數被重置。若 BIOS 正常持續運作，timer 永遠不會歸零。
如果 BIOS 卡住了？
一旦 BIOS 停止送 POST code、也沒有 PLDM/IPMI watchdog command，phosphor-watchdog 的 timer 就會開始繼續倒數。當時間歸零時，它的回呼函式 timeOutHandler() 被觸發。
這個函式會先查詢「超時要做什麼」（例如 HardReset），然後：
- 發送 D-Bus method call 給 systemd，
- 請它啟動對應的
.service單位， - 而該 service 又會進一步觸發底層的硬體 reset target。
當開機完成，Watchdog 應該關閉
開機順利完成後，Host State Manager（或 BIOS）會通知 BMC：「我完成了」。這時候它會透過 D-Bus 把 Enabled 設為 false。phosphor-watchdog 收到這個屬性變更後，就會呼叫tryFallbackOrDisable()，將計時器關掉。
這樣，即使 OS 沒繼續踢狗，也不會誤以為開機掛掉而重啟。除非有設定 fallback，watchdog 才會繼續以預設間隔監控。
花絮補充
大家也許有機會在工作中聽到工程師說...啊系統卡在FRB幾....那到底是在說什麼挖溝咧？FRB全名前面有提過就是Fault Resilient Booting，早期IPMI講開機階段分成三個主要層級：
FRB-1：CPU Reset Initialization
這是最早期的階段——當主機板剛通電，CPU 剛離開 reset 狀態。在這個階段，BMC 會啟動一個極短的 timer（通常幾秒），等待 BIOS 第一次送出「我開始執行了」的信號。 如果 BIOS 還沒開始跑，BMC 會假定 CPU 沒起來，重新發一次 reset。 這確保了在晶片上電或 power-good 信號異常時，系統不會卡死。
FRB-2：POST（Power-On Self-Test）
當 BIOS 開始跑 POST code（記憶體測試、PCIe 掃描、初始化控制器）， 它會在每個階段發一個 “kick” 給 BMC。 這通常是透過 IPMI 指令 Reset Watchdog Timer 或寫入 POST port (0x80) 實現的。
只要 BMC 一直收到這些訊號，就會不斷重置 timer。 但如果某個 POST 卡住，例如記憶體訓練或 DIMM 初始化沒回應， 那麼倒數結束後，BMC 就會主動重啟整台機器。 這就是所謂的 FRB-2 Watchdog。
FRB-3：OS Boot Load 階段
這階段發生在 BIOS 完成 POST、開始交棒給作業系統的時候。在傳統系統裡，BMC 會再啟一個新的 watchdog， 等 OS 透過 IPMI Set Watchdog Timer 重新接管。這樣可以確保「如果 OS 永遠沒起來（bootloader 掛掉）」的情況，也能自動復原。
但我仔細回想了一下，並不是我所有做過的案子都有完整走完整個開機的這些流程，有時候只有到FRB2，然後就結束了，後面可能是透過其他sensor的表現或者error狀態的處理來監控系統是不是有正常的運作，也不一定完全仰賴Watchdog...所以我覺得我們在認識SPEC設計的同時，也是要去思考現在手上的產品他真正的需求是什麼？Data Center的環境和狀態是如何？ 來和cross function team一起設計出最適合自己案子的做法，這樣比較實在！ ：）
