NVMe 自問自答題庫：Reset 與 Shutdown

NVMe · Q1–328

NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

Q174–Q187

Reset 與 Shutdown

Reset 結束操作環境，Shutdown 準備安全停止；兩者的目的和完成證據不同。先看影響範圍，再分辨哪些狀態需要重建，哪些操作仍持續。

每個問題都接著完整解說，依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽，再沿問題閱讀；必要條件與正常路徑直接顯示。所有數字案例均為教學假設；Status 以 SCT/SC 表示，代碼後的 h 代表十六進位。

SCT
Status Code Type，完成狀態代碼類型

停止的要求與停止的完成

Host 寫入要求不等於 controller 已完成；等待條件必須看回報狀態。

動作要求完成後的主要處理
Controller ResetCC.EN→0等 RDY=0，重建 queues
Subsystem Reset適用的 reset 介面確認全部受影響 controller
Normal ShutdownCC.SHN=01b等 SHST=10b，核對斷電範圍
Abrupt ShutdownCC.SHN=10b仍觀察完成狀態

舉例看懂：Normal 要求送出後若 SHST 還未完成就掉電，仍可能增加 UPL；Abrupt 已完成後才掉電則不必然增加。關鍵是掉電當時狀態。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3

需要時回顧本篇名詞
Controller / namespace
controller 接收命令並管理存取；namespace 是命令可指定的一份邏輯儲存空間。NVM subsystem 則包含 controller 與非揮發儲存資源，同一 subsystem 可以有多個 controller。
SQ / CQ / SQE / CQE
Submission Queue（SQ）是提交佇列，Completion Queue（CQ）是完成佇列；SQE 與 CQE 分別是其中的一筆命令及完成項目。QID 識別 queue，CID 區分同一 SQ 中尚未完成的命令，NSID 則識別 namespace。
Register / Identify / Feature / Log
Register 提供可存取的控制或狀態資訊；Identify 查詢物件的能力與屬性；Feature 用來讀取或變更工作設定；Log Page 回報特定種類的狀態或紀錄。FID、LID、CNS、CSI 則分別用來選擇 Feature、Log Page、Identify 資料結構及命令集。
index / offset / zero-based
index 指出清單中的第幾筆，通常從 0 起算；offset 表示與起點相隔多遠，解讀時必須確認單位。若數量欄位採 zero-based 編碼，實際數量等於欄位值加 1；但不是所有欄位看到 0 都要加 1。Dword 是 4 bytes，1 byte 是 8 bits。
Scope / reset / retention
scope 表示操作影響哪些物件；retention 表示狀態是否保留。清除 CC.EN 所觸發的 Controller Reset，是 Controller Level Reset（CLR）的一種。同屬 CLR 的不同觸發方式，仍可能採用不同的 Register 保留規則。

本冊題目

  1. Q174 · Controller、Subsystem 與 Queue Level Reset 範圍有何不同？
  2. Q175 · Conventional、FLR、Hot 與 Fundamental Reset 如何對應 NVMe？
  3. Q176 · Reset 發生在 Idle、命令或背景操作中，如何判斷結果？
  4. Q177 · Reset 期間 CSTS.RDY 應如何變化？
  5. Q178 · Reset 後哪些 Register、Feature 與 Queue 要重建？
  6. Q179 · Reset 後舊 Outstanding 與 Completion 應如何處理？
  7. Q180 · Reset 後如何確認 Feature、Log、Namespace 與 Firmware？
  8. Q181 · Reset 超時或 CFS 未清除時怎麼辦？
  9. Q182 · Host 如何用 CC.SHN 做 Normal Shutdown？
  10. Q183 · 何時算 Shutdown Complete，可以移除電源？
  11. Q184 · Normal、Abrupt Shutdown 與直接斷電有何不同？
  12. Q185 · Shutdown 期間能否繼續新命令或保留 Outstanding？
  13. Q186 · Normal／Abrupt 如何影響 Unsafe Shutdowns？
  14. Q187 · 非正常失電後為何查 SMART、Error 與 PEL？

Q174 Controller、Subsystem 與 Queue Level Reset 範圍有何不同？

跟著解說理解

選擇合適的範圍，才能恢復故障並掌握哪些工作會被中止。

1. 差別在哪裡

Queue Reset 刪除重建指定 I/O queue；CLR 重設一個 controller 的命令環境；Subsystem Reset 涵蓋一個或全部 domains。

Queue Reset 用 Delete／Create；Controller Reset 清 CC.EN；NSSR.NSSRC 寫 4E564D65h 請求支援的 Subsystem Reset。

2. 如何選擇與確認

查 CAP.NSSRS、controller／domain 拓樸與 queue 相依關係。

停止受影響提交，選擇範圍，完成等待與重建，再恢復命令。重建 CQ 前先處理依賴它的 SQ。

CQ
Completion Queue，完成佇列
SQ
Submission Queue，提交佇列

新 queue 或 controller 恢復可用，原使用期間的追蹤不再沿用。

3. 比較時要保留的條件

Register 觸發 Reset 沒有 CQE；Delete／Create 才有其命令完成。

CQE
Completion Queue Entry，佇列中的完成項目

用實際被刪除的 queues 與受影響 controllers 驗證範圍，不能只看 Host 函式名稱。

4. CQE、DNR 與 More 在這裡是否適用

CQE
Completion Queue Entry，佇列中的完成項目
DNR
Do Not Retry，命令重試的狀態提示

Queue Level Reset 若透過 Delete／Create 命令處理，要解讀各命令的 CQE；CC.EN 與 NSSR 等 Register 操作沒有 NVMe CQE，因此沒有 DNR／More。不能將這幾種機制的回報方式混用。

DNR
Do Not Retry，命令重試的狀態提示

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q175 Conventional、FLR、Hot 與 Fundamental Reset 如何對應 NVMe？

FLR
Function Level Reset，以功能為範圍的重設
跟著解說理解

本題只教 NVMe 可觀察的重設效果，不展開 Link 或封包。不同來源會影響 Register 保留與韌體啟用。

1. 差別在哪裡

FLR 針對 function；Conventional Reset 包含適用的 Hot／Fundamental 形式，實際影響須依裝置拓樸確認。

FLR
Function Level Reset，以功能為範圍的重設

PCIe Transport3.3 將 Conventional 與 FLR 列為 CLR 來源；CC.EN 的 Controller Reset 不重設 PCI configuration space。

2. 如何選擇與確認

確認 PCIe reset 支援、CAP 與待啟用 Firmware Commit 要求。

記錄實際來源，恢復適用 PCI 配置，再執行 NVMe 初始化。

受影響 NVMe queues 依 CLR 重建；不能期待 FLR 保留 I/O queues。

3. 比較時要保留的條件

要求 Conventional Reset 才能啟用的映像，不會因 FLR 或 CC.EN Reset 提前啟用。

CMBMSC 對 FLR 另有保留例外，不能概括成所有 Register 皆歸零。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q176 Reset 發生在 Idle、命令或背景操作中，如何判斷結果？

跟著解說理解

Reset 對命令通道與背景操作可能有不同效果，不能只用「全部中止」概括。

1. 先界定觸發方式與影響對象

受影響 queues 結束，但資料與持久管理狀態各依自己的規則。

保存 outstanding 清單、操作 Log 與 Reset 來源。

2. 哪些狀態改變，恢復後怎麼處理

Sanitize 持續；Short Self-test 中止；Extended Self-test 恢復；未 Commit 的 firmware 下載丟棄。

Reset 前記錄階段，恢復後讀對應 Log 與 Identify，不憑舊 CQE bytes 猜結果。

逐項判定完成、中止、持續或仍未知，再決定後續。

3. 如何驗證保留或恢復結果

沒有 CQE 不等於沒執行；Reset 不保證 Write 回復成舊資料。

按各功能的持久性驗證，不要求所有功能有同一結果。

先區分命令本身與它啟動的背景工作。

來源：Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q177 Reset 期間 CSTS.RDY 應如何變化？

跟著解說理解

RDY 確認停用或重新就緒，不能以 Host 寫入 EN 代替觀察。

1. 操作前先準備什麼

RDY 是 controller 狀態，不保證每個 namespace ready。

讀 CAP.TO、Ready Mode 與 CRTO 能力。

清 EN 後等 RDY=0；重新設 EN=1 後按正確期限等 RDY=1。

2. 先後順序與完成條件

停用完成前不重新 Enable，先完成新環境設定再啟用。

RDY 轉移與所選模式一致；media 尚未就緒時仍遵循模式限制。

3. 未符合條件時如何處理

Register 讀取失敗不能當成 RDY=0 證據。

保存 EN、RDY、CFS 與時間，區分請求與確認。

來源：Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q178 Reset 後哪些 Register、Feature 與 Queue 要重建？

跟著解說理解

重建依 Reset 來源與 Feature 規則，不能照抄舊記憶體。

1. 操作前先準備什麼

I/O queues 失效、Admin 指標重設；持久 namespace 與 Saved 設定是另一層。

查 Register 例外、Feature 能力／Current 與 queue 配額。

CC.EN Reset 保留 AQA／ASQ／ACQ、指定 PMR registers 與 CMBMSC，但不保留 queue 指標。

PMR
Persistent Memory Region，持久性記憶體區域

2. 先後順序與完成條件

恢復必要 PCI／Register 設定，初始化 Admin Phase，Enable 等 RDY，配置功能，再建 CQ／SQ。

CQ
Completion Queue，完成佇列
SQ
Submission Queue，提交佇列

新 queue 正常完成命令，Current Feature 符合恢復規則。

3. 未符合條件時如何處理

保留位址不代表舊 CQE 有效；不可保存 Feature 也不一定回零。

比較 Saved、Current 與例外，不用「全部歸零」的固定斷言。

來源：Base 2.4 §4.4 · Base 2.4 §3.1.4 (AQA, ASQ, ACQ, CMBLOC) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §4.4 · Base 2.4 §3.1.4 (AQA, ASQ, ACQ, CMBLOC) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q179 Reset 後舊 Outstanding 與 Completion 應如何處理？

跟著解說理解

避免舊完成誤配新 CID，以及舊命令晚到的存取干擾新工作。

CID
Command Identifier，同一提交佇列內的命令識別碼

1. 先界定觸發方式與影響對象

追蹤按 queue 使用期間隔離，共享資料的其他 controller 也可能參與復原。

保存 Reset 完成證據與舊 SQID／CID 清單。

SQID
Submission Queue Identifier，提交佇列識別碼
CID
Command Identifier，同一提交佇列內的命令識別碼

2. 哪些狀態改變，恢復後怎麼處理

重新初始化 Phase 與指標，不把 Reset 前 CQE 當新完成。

確認舊處理已停止，再回收資源或由其他 controller 重試改寫命令。

每筆新命令只收到新使用期間的結果；舊命令資料效果另行確認。

3. 如何驗證保留或恢復結果

失去通訊時不能要求全部舊命令回固定 Abort Status。

區分 controller 新寫入與記憶體殘留的 CQE。

先查 Phase 初始化與 CID 重用紀錄。

來源：Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q180 Reset 後如何確認 Feature、Log、Namespace 與 Firmware？

跟著解說理解

RDY=1 之外，還要知道哪些設定恢復、哪些背景操作持續。

1. 操作前先準備什麼

依 controller、namespace、subsystem 的各自範圍查詢。

使用受支援的 Identify、Get Features 與 Logs。

Feature 查 Current／Saved；namespace 查身分與清單；firmware 查 FR／slots；背景操作查對應 Log。

2. 先後順序與完成條件

恢復 Admin 通道後查狀態，再建立與新格式／能力一致的 I/O 環境。

變化應能解釋，例如 Sanitize 進度延續，但舊 AER 已失效。

3. 未符合條件時如何處理

Error entries 清除而計數保留可以同時符合規範。

按持久、恢復及即時欄位分類比對。

來源：Base 2.4 §4.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.38 · Base 2.4 §5.2.13.1.7 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §4.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.38 · Base 2.4 §5.2.13.1.7 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q181 Reset 超時或 CFS 未清除時怎麼辦？

跟著解說理解

先區分期限用錯與持續故障，不無限重送。

1. 先保留哪些證據

先處理該 controller，擴大範圍前確認平台支援及其他使用者。

保存 CAP／CRTO、EN／RDY／CFS、來源與時間。

停用用 CAP.TO，啟用依 Ready Mode；fatal recovery 依 Base9.5。

2. 依什麼順序排除原因

先核對期限與 controller 角色。

確認讀值有效，先 Controller Reset；CFS 仍未清除才評估適用的 Subsystem Reset。

3. 把觀察結果接回規格條件

恢復後狀態與命令通道都可用，不只是一個 CFS 位元清零。

不能以任意更短的 Host timeout 判違規，也不盲目要求不適合平台的 Subsystem Reset。

先排除 Secondary Offline 預期造成的 CFS。

來源：Base 2.4 §9.1–9.6.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §9.1–9.6.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q182 Host 如何用 CC.SHN 做 Normal Shutdown？

跟著解說理解

Normal Shutdown 準備保存與媒體關機，不等於停用 controller。

1. 操作前先準備什麼

可斷電範圍須依 CAP.CPS 協調相關 controllers。

讀 CPS、RTD3E、SHST 與 ST。

SHN=01b 要求 Normal；SHST=10b、ST=0 表示 controller shutdown 完成。

2. 先後順序與完成條件

停止新 I/O 並等既有命令，建議刪 SQ 再刪 CQ，最後設 SHN 並等待。

完成後可斷電狀態持續到規定的狀態改變事件。

3. 未符合條件時如何處理

寫 SHN 沒有 CQE；處理中命令可被 Power Loss Notification Status 中止。

確認實際 SHST，不能只看送出 SHN。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q183 何時算 Shutdown Complete，可以移除電源？

跟著解說理解

發出通知不等於完成保存，需等實際完成狀態。

1. 操作前先準備什麼

domain／subsystem scope 須全部相關 controllers ready。

查 SHST、ST、CPS 與 RTD3E。

SHST01b=處理中，10b=完成；一般 controller shutdown 用 ST0。

2. 先後順序與完成條件

輪詢完成；RTD3E=0 時建議至少等待 1 秒供處理，不是到 1 秒就無條件拔電。

所需範圍皆 ready-to-power-off 才符合建議。

3. 未符合條件時如何處理

之後 Reset 或允許的媒體存取可能使先前 readiness 失效。

用最後狀態與實際失電時點比對，不忽略中間操作。

來源：Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q184 Normal、Abrupt Shutdown 與直接斷電有何不同？

跟著解說理解

Normal 與 Abrupt 都有通知；直接失電可能沒有準備時間。

1. 差別在哪裡

流程不同會影響未完成工作與持久性，但仍需確認 power scope。

SHN01b／10b 分別選 Normal／Abrupt，兩者都用 SHST10b 回報完成。

2. 如何選擇與確認

保存 SHN、SHST、power 事件及 SMART.UPL。

Normal 建議排空與刪 queue；Abrupt 停止新 I/O 再通知；直接斷電無法等待。

Abrupt 若完成且失電時仍 ready，不必只因名稱就增加 UPL。

3. 比較時要保留的條件

未完成 volatile writes 的持久性不能只靠 Shutdown 名稱保證。

分別觀察要求、完成與失電三個時點。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q185 Shutdown 期間能否繼續新命令或保留 Outstanding？

跟著解說理解

持續提交新 I/O 會妨礙有序關機，因此先停止新工作。

1. 機制與適用範圍

I/O 與 Admin 不同，AER outstanding 不等於資料尚未寫完。

正常流程排空 I/O；Admin 是否先 Abort 由 Host 選擇，完成時建議只剩 AER。

2. 用操作與結果理解

觀察 outstanding 清單與 SHST。

停止新工作並處理既有結果，送 SHN 後不任意清 EN 影響關機時間。

SHST 完成可與 pending AER 並存。

3. 容易誤判的地方

處理中命令可因 Power Loss Notification 被中止，不保證晚到命令成功。

確認 Host 沒把 AER 計入資料排空條件。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q186 Normal／Abrupt 如何影響 Unsafe Shutdowns？

跟著解說理解

Base2.4 改稱 Unexpected Power Losses（UPL），依真正失去 main power 時的狀態計數。

1. 機制與適用範圍

UPL 是 SMART 生命週期資訊，不是每筆 Shutdown 的結果。

main power 失去且 SHST≠10b 時必須增加；另有 out-of-band Ignore Shutdown 導致媒體不在 shutdown state 的條件。

2. 用操作與結果理解

讀 LID02h bytes144～159，保存失電前狀態。

先取基準，發通知並等完成，再移電與查增量；記錄中途媒體重新啟用。

完成且保持 ready 的 Normal 或 Abrupt，不因名稱增加 UPL；未完成便失電則增加。

3. 容易誤判的地方

沒有真正 power loss 的 Reset 不必增加 UPL。

依 if-and-only-if 條件驗證，排除額外失電及錯誤取樣。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

本題原文定位

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

Q187 非正常失電後為何查 SMART、Error 與 PEL？

跟著解說理解

各資料補充計數、目前錯誤與持久事件，填補失電時沒有 CQE 的觀察空白。

1. 先保留哪些證據

使用相同身分，分清累計與即時狀態。

確認 PEL 支援與事件，使用正確 LID。

LID
Log Page Identifier，紀錄頁識別碼

SMART 看 UPL／Power Cycles／MDIE，Error 看 ECNT，PEL 看 Reset 與相關操作。

2. 依什麼順序排除原因

先保存恢復後第一份快照。

恢復 Admin 後先保存 Log，再做可能覆寫歷史的測試。

3. 把觀察結果接回規格條件

可知道失電與未確認操作；無 Error entry 不代表資料全部安全。

Error entries 建議於 power cycle 清除，空 Log 不必然違規，持久 counters 另看。

比較計數、事件及電源時間線，不要求紀錄一對一。

來源：Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2

本題原文定位

來源：Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2

回本冊題目

原文定位與既有圖表判讀

Base 的文件頁碼等於 PDF 頁碼減 26；NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題，只引用本題需要的定義，不納入 Fabrics 或 PCIe Link、封包內容。

  • Base 2.4 · §3.1.4 (CAP, VS)
    文件頁 54–59 · PDF 80–85 · Figure 36–37
  • Base 2.4 · §3.1.4 (CC, CSTS, NSSR)
    文件頁 60–66 · PDF 86–92 · Figure 41–43
  • Base 2.4 · §3.1.4 (AQA, ASQ, ACQ, CMBLOC)
    文件頁 66–68 · PDF 92–94 · Figure 44–47
  • Base 2.4 · §3.1.4 (CRTO)
    文件頁 72–73 · PDF 98–99 · Figure 57
  • Base 2.4 · §3.6–3.6.1 (memory-based scope and shutdown)
    文件頁 113–115 · PDF 139–141 · Figure 85
  • Base 2.4 · §3.7.1–3.7.4
    文件頁 120–124 · PDF 146–150
  • Base 2.4 · §3.11–3.11.1, 5.2.9–5.2.10
    文件頁 135–138, 202–206 · PDF 161–164, 228–232 · Figure 187–193
  • Base 2.4 · §4.2.3
    文件頁 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §4.4
    文件頁 166–169 · PDF 192–195 · Figure 126–127
  • Base 2.4 · §5.2.2
    文件頁 183–190 · PDF 209–216 · Figure 150–156
  • Base 2.4 · §5.2.6, 8.1.8
    文件頁 199–201, 614–616 · PDF 225–227, 640–642 · Figure 176–180, 700–701
  • Base 2.4 · §5.2.13.1.2
    文件頁 218–220 · PDF 244–246 · Figure 212
  • Base 2.4 · §5.2.13.1.3
    文件頁 220–225 · PDF 246–251 · Figure 213–214
  • Base 2.4 · §5.2.13.1.7
    文件頁 229–232 · PDF 255–258 · Figure 218–219
  • Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
    文件頁 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
  • Base 2.4 · §5.2.13.1.38
    文件頁 313–320 · PDF 339–346 · Figure 312
  • Base 2.4 · §5.2.26–5.2.27
    文件頁 448–454 · PDF 474–480 · Figure 451–455
  • Base 2.4 · §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2)
    文件頁 825–828 · PDF 851–854
  • Base 2.4 · §9.1–9.6.1
    文件頁 825–826 · PDF 851–852
  • PCIe Transport 1.4 · §3.3
    文件頁 11–12 · PDF 11–12

需要看欄位圖時

以下連結可開啟對應的圖表教學，查閱欄位及判讀方式。每張圖保留固定的教學位置，方便之後反覆查詢。

使用的原始文件
  • NVM Express Base Specification · Revision 2.4 · 2026-07-31
    NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
  • NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
    NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
  • NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
    NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf
Jia-Chang

Jia-Chang

Human

Recent posts

PCIe Chapter 37：效能推估與跨章觀察
PCIe Chapter 37: Performance Estimation and Integrated Observation
PCIe Chapter 36：交易依賴、ID-Based Ordering 與 Message
PCIe Chapter 36: Dependencies, ID-Based Ordering, and Messages

Comments

  Write a comment ...