[chassisd] Capture DPU reboot cause via boot_id and add midplane-down reason for Smart Switch#850
Conversation
NPU chassisd able to read boot_id and update and persist add subscribe to chassisd add tests add persist previous midplane down reason Signed-off-by: Charles Tsai <chartsai@nvidia.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks! ---Powered by SONiC BuildBot
|
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1154977: ✅Stage __default: |
|
Hi @sonic-net/sonic-platform-daemons-maintainer, this approved PR has workflow run(s) waiting for approval. Please help review. Thanks! ---Powered by SONiC BuildBot
|
5 similar comments
|
Hi @sonic-net/sonic-platform-daemons-maintainer, this approved PR has workflow run(s) waiting for approval. Please help review. Thanks! ---Powered by SONiC BuildBot
|
|
Hi @sonic-net/sonic-platform-daemons-maintainer, this approved PR has workflow run(s) waiting for approval. Please help review. Thanks! ---Powered by SONiC BuildBot
|
|
Hi @sonic-net/sonic-platform-daemons-maintainer, this approved PR has workflow run(s) waiting for approval. Please help review. Thanks! ---Powered by SONiC BuildBot
|
|
Hi @sonic-net/sonic-platform-daemons-maintainer, this approved PR has workflow run(s) waiting for approval. Please help review. Thanks! ---Powered by SONiC BuildBot
|
|
Hi @sonic-net/sonic-platform-daemons-maintainer, this approved PR has workflow run(s) waiting for approval. Please help review. Thanks! ---Powered by SONiC BuildBot
|
Why I did it
On Smart Switch platforms,
chassisdneeds a reliable way to detect when a DPU hasrebooted and to record the correct reboot cause for it. The previous approach inferred
reboots from midplane operational-status transitions and time-window heuristics, which was
fragile and could miss or misattribute reboots. This change switches to a deterministic
signal: the DPU publishes its kernel
boot_id, and the NPU captures the reboot causewhenever that
boot_idchanges. It also adds a proper midplane-down reason(Planned vs. Unplanned) per HLD rev 0.7.
Work item tracking
How I did it
DpuStateUpdater/DpuStateManagerTask): read the kernelboot_idfrom/proc/sys/kernel/random/boot_idand publish it into theDPU_STATEtable inCHASSIS_STATE_DB, updating it only when it changes.SmartSwitchModuleUpdater): addcheck_dpu_boot_id_changes()to capture andpersist the reboot cause when a DPU's
boot_idchanges (only while the midplane isreachable), and load persisted
boot_ids on startup fromprevious-reboot-cause.json.RebootCauseSubscriberTask, which subscribes toDPU_STATEchanges and triggersreboot-cause capture on
boot_idupdates, replacing the old status-transition /time-window reboot heuristic.
boot_idalongside the reboot-cause record and simplify the history file namingby removing the separate
prev_reboot_time.txtbookkeeping._resolve_midplane_down_reason()to classify midplane up->down transitions asPlanned (from the STATE_DB transition flag/type) or Unplanned (from the platform's
get_midplane_down_reason()), and write it intodpu_midplane_link_reason.How to verify it
tests/test_chassisd.py, with new mock support intests/mock_module_base.py(midplane-down reason constants) andtests/mock_platform.py(
get_module_state_transition/get_midplane_down_reason) to coverboot_idcaptureand the Planned/Unplanned midplane-down reason logic.