NVMe 自問自答題庫：Device Self-test
read more
NVMe 自問自答題庫：Device Self-test
NVMe · Q1–328
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Q149–Q156
Device Self-test
Self-test 將裝置內部診斷結果回報給 Host。先確認能啟動哪種測試，再分清進度、最終結果與失敗欄位有效性。
每個問題都接著完整解說，依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽，再沿問題閱讀；必要條件與正常路徑直接顯示。所有數字案例均為教學假設；Status 以 SCT/SC 表示，代碼後的 h 代表十六進位。
- SCT
- Status Code Type，完成狀態代碼類型
啟動、執行、結果是三種資訊
啟動 CQE 成功，不表示測試通過。
- CQE
- Completion Queue Entry，佇列中的完成項目
| 觀察 | 欄位／介面 | 用途 |
|---|---|---|
| 可否執行 | OACS、DSTO | 確認支援與並行條件 |
| 目前執行 | Current Operation、Completion Percentage | 了解還在做什麼 |
| 本次結果 | 最新 Result 的 DSTC、DSTR | 辨識通過、失敗或中止 |
| 失敗細節 | VDINFO、SEGN、FLBA | 只有有效欄位才可推論 |
舉例看懂：Short 在 CLR 下需要中止；Extended 有跨 CLR 持續與失電恢復的規則。不能只看測試名稱都有 Self-test，就要求相同 reset 結果。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.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 保留規則。
本冊題目
- Q149 · 如何確認 Device Self-test 支援與可測範圍？
- Q150 · Short 與 Extended Self-test 有何差別？
- Q151 · Self-test 進行中再次啟動或要求中止會怎樣？
- Q152 · Current Operation 與 Completion Percentage 如何解讀？
- Q153 · 成功、失敗、中止、Reset 與斷電後的 Self-test 結果怎麼看？
- Q154 · Self-test 完成一定有 Asynchronous Event 嗎？
- Q155 · Segment、Diagnostic Information 與 Failing LBA 何時有效？
- Q156 · Self-test 結果如何排列，超過 20 次後怎麼辦？
Q149 如何確認 Device Self-test 支援與可測範圍？
跟著解說理解
Self-test 提供裝置內部的診斷流程，可檢查 controller 與指定媒體，但它不能取代 Host 對資料內容的完整驗證。
1. 要查哪個對象、哪份資料
NSID=0 只測 controller；特定 active NSID 加入該 namespace；FFFFFFFFh 包含開始時此 controller 可存取的全部 attached namespaces。
- NSID
- Namespace Identifier，邏輯儲存空間識別碼
Identify.OACS 確認支援，DSTO.SDSO 決定單一測試限制的範圍，EDSTT 提供延伸測試時間。
Device Self-test 使用 STC 選操作；Get Log Page LID06h 查目前測試與最近 20 次結果。
2. 查詢順序與回覆判讀
先確認能力與 namespace 狀態，保存舊 Log，再啟動選定測試並追蹤新狀態。
啟動成功表示背景測試已開始；真正通過要看新 Result 的 DSTR=0，而非只看啟動 CQE。
- CQE
- Completion Queue Entry，佇列中的完成項目
3. 證據不足或不一致時怎麼判斷
不存在的 NSID 回 Invalid Namespace or Format；已配置但 inactive 的 NSID 回 Invalid Field in Command，這兩種情況不能混寫。
核對 OACS、實際 STC、NSID 與 Log 的測試代碼，確認啟動的是預期測試。
先確認「不存在」與「存在但未 active」的差別。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q150 Short 與 Extended Self-test 有何差別？
跟著解說理解
兩者提供不同深度與時間的診斷；實際 segments 與測試內容由廠商設計，規格中的 RAM／媒體檢查圖只是教學示例。
1. 差別在哪裡
兩者都依 NSID 選範圍，且可能因共享資源影響其他工作的效能。
STC=1 啟動 Short，2 啟動 Extended；Log 的 DSTOS 表示正在執行哪種操作，DSTCS 表示完成百分比。
2. 如何選擇與確認
EDSTT 是延伸測試時間資訊；短程測試建議在 2 分鐘內完成。這些 should 不應提升為所有情況的硬性 shall。
依所需診斷與可接受影響選測試，保存開始時間並查進度；若命令需要暫停測試，controller 先暫停、完成該命令，再恢復測試。
測試結束後由 Result 判定成功或哪個 segment 失敗；短程通過不保證延伸測試也必然通過。
3. 比較時要保留的條件
關鍵差異是 Reset：Short 必須被影響它的 CLR 中止；Extended 必須跨 CLR 與恢復供電後繼續。
驗證時間時保留其他工作與暫停因素；驗證 Reset 時分別套用兩種測試規則。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q151 Self-test 進行中再次啟動或要求中止會怎樣？
跟著解說理解
避免同一限制範圍同時跑多個測試，並提供明確的背景操作中止方法。中止 Self-test 操作應使用 STC=Fh。
1. 先區分是哪一種失敗
DSTO.SDSO=0 以 controller 判斷是否已有測試；SDSO=1 則以 subsystem 判斷。
STC1／2／3 為新操作；Fh 中止；Eh 是廠商特定，互動規則也可能不同。
已有測試時再送 1／2／3，回 Device Self-test In Progress（1/1Dh）；不能要求它默默重啟原測試。
2. 用哪些資料確認原因
先讀 DSTO 與 LID06h；只看目前 controller 的 Host outstanding 清單不足以知道另一端是否已開始測試。
已有測試時送 Fh，controller 先中止、建立最新結果，再將目前操作設為 idle，最後完成命令。
3. 結果與後續驗證
沒有測試時送 Fh 仍成功，且不修改 Self-test Log；不能為這次空中止捏造新結果。
核對中止 CQE 前 Log 更新順序，以及新結果 DSTR=1，避免把 idle 當成唯一證據。
先查使用的是 STC=Fh，還是誤用 Abort 去中止早已完成的啟動命令。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q152 Current Operation 與 Completion Percentage 如何解讀？
跟著解說理解
Log 開頭描述正在執行的工作，後面的 Result List 描述已結束的測試。兩者可能同時存在，不應用舊結果取代當前進度。
1. 先確認資料的來源與範圍
依測試的 controller／共享範圍讀正確 Log，並保存取樣時間。
先確認支援，再使用 LID06h 的 CDSTO、CDSTC 與 RDS1。
2. 欄位、單位與判讀例子
DSTOS=0 為無操作，1 為 Short，2 為 Extended，3 為 Host-Initiated Refresh；DSTCS 的值 25 代表 25%，不是零起算 26%。
先讀 DSTOS，只有有操作時才解讀 DSTCS；idle 時應忽略百分比，再查看最新 Result。
Short／Extended 結束時，必須先建立結果才清 DSTOS。讀到 idle 並搭配新 Result，才知道操作如何結束。
3. 判讀時要保留的條件
百分比不動不一定失敗，可能測試在某個 segment 或被其他命令暫停；也不能把 100%欄位當成全部結果。
比較連續快照的 operation、進度與最新結果，避免只用一個百分比斷言韌體卡住。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q153 成功、失敗、中止、Reset 與斷電後的 Self-test 結果怎麼看？
跟著解說理解
測試結果需要保留原因，才能區分裝置診斷失敗與 Host 主動中止。Extended 因 Reset 暫停後恢復，不應被錯記成測試已失敗。
1. 先界定觸發方式與影響對象
結果屬於一次測試，包含當時測試代碼與時間；不是啟動命令的 CQE Status。
用 LID06h 的 DSTR、DSTC、POH 及 valid diagnostic fields。
2. 哪些狀態改變，恢復後怎麼處理
DSTR0=成功，1=Self-test 命令中止，2=CLR 中止，3=namespace 移除，4=Format，5=致命或未知測試錯誤，6／7=segment 失敗，8=未知中止，9=Sanitize 中止。
先判斷 Short 或 Extended，再對照中止事件。Short 遇 CLR 結束；Extended 跨 Reset／恢復供電繼續，之後才產生最終結果。
成功用 DSTR0；已知 segment 失敗用 7 並提供 SEGN；沒有新結果可能是 Extended 仍在恢復執行，不可直接判定 Log 遺漏。
3. 重設或斷電時，要確認什麼
| 觸發方式 | 這項操作或狀態會如何變化 |
|---|---|
| Controller Reset 後是否保留或繼續？ | 影響執行 controller 的 Controller Level Reset 必須中止短程測試；延伸測試則必須跨 CLR 保留，並在重設完成後恢復。恢復的 segment 由廠商決定，規範建議只需重做被中斷的最後 segment。 |
| NVM Subsystem Reset 後是否保留或繼續？ | Subsystem Reset 會對其範圍內的 controller 造成 CLR：短程測試被中止，延伸測試必須恢復。不能把重新建立 Admin Queue 與重新開始整個延伸測試當成同一件事。 |
| Power Cycle 後是否保留或繼續？ | 延伸測試必須在電源恢復後繼續；短程測試則不具有這項延續要求。恢復後先讀 DSTOS、進度與最新結果，不能只因 power cycle 就期待兩者都新增 Reset-aborted 結果。 |
4. 如何驗證保留或恢復結果
規格沒有 Power Loss 專屬 DSTR 值；不能自創代碼。Format 是否中止測試還需依 Figure701 的 scope 組合。
比對外部 Reset／Format／Sanitize 時間、測試類型及 Log，確認結果原因能互相解釋。
先確認 Extended 是否本來就應該繼續，避免把沒有 Reset-aborted Result 視為錯誤。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q154 Self-test 完成一定有 Asynchronous Event 嗎？
跟著解說理解
正常 Self-test 完成要從 Device Self-test Log 判斷；規範沒有定義通用的 Self-test Completed 通知，因此不能把等到 AER 當成完成條件。
1. 正常測試完成，要看哪裡
啟動命令先完成，背景測試稍後結束；兩者不同，也不會自動轉成 AER。
啟動後定期讀 DSTOS 與新 Result；收到診斷錯誤事件時再查補充 Error Information，並與測試結果關聯。
正常完成且沒有 AER 可以符合規範；有診斷失敗事件也仍須讀具體結果，不能只用事件當完整診斷。
2. Diagnostic Failure 是另一種通知
查 Self-test 能力與 LID06h；診斷失敗另看 Error 類型的 Diagnostic Failure 定義。
Diagnostic Failure 的 AET=0、AEI=02h，與 Device Self-test Log 的 DSTR 不同；不是把 DSTR 全部放進 AER。
以實際定義的事件與 Log 驗證，避免把 Sanitize Completed 的機制套到 Self-test。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q155 Segment、Diagnostic Information 與 Failing LBA 何時有效？
- LBA
- Logical Block Address，邏輯區塊位址
跟著解說理解
欄位有值不代表有效。有效位元讓 Host 避免把保留或未知資料當成精確故障位置。
1. 先確認資料的來源與範圍
SEGN 指內部測試 segment；FLBA 指 namespace 的 logical block，兩者沒有固定換算關係。
先看 DSTR，再看 VDINFO 的 NSIDVLD、FVLD、SCTVLD、SCVLD。
2. 欄位、單位與判讀例子
只有 DSTR=7 時 SEGN 表示第一個已知失敗 segment；FLBA 只有 FVLD=1 才有效，NVM 定義它是造成失敗的某一個 LBA。
- LBA
- Logical Block Address，邏輯區塊位址
先確認結果非空，再確認各 valid bit，最後用有效 NSID 與 FLBA 對回 namespace；沒有有效 NSID 時，不能自行猜測其歸屬。
多個 LBA 失敗時，只回其中一個是合法，不保證列出全部，也不保證是最低 LBA。
3. 判讀時要保留的條件
無效欄位應忽略，不要因其值超範圍就判違規；同時，也不能忽略已宣告有效但明顯錯誤的內容。
以有效位元、測試結果與格式共同驗證，區分「未知位置」與「已知位置不合理」。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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)
Q156 Self-test 結果如何排列，超過 20 次後怎麼辦？
跟著解說理解
固定大小歷史讓 Host 查最近測試，但不能當成裝置出廠以來所有診斷的永久清單。
1. 機制與適用範圍
LID06h 保存 20 個結果，每個 28 bytes，前 4 bytes 是目前狀態。
RDS1 最新，RDS2 次新，依序到 RDS20。未使用 entry 的 DSTR=Fh、DSTC=0，其他欄位應忽略。
2. 用操作與結果理解
使用 Log 固定結構與 DSTC／DSTR 空 entry 規則，不要用全零判斷是否有效。
測試前保存 RDS1，完成後確認新結果移到第一筆，舊結果向後排列；超過容量後最舊結果不再列入最近 20 次。
第 21 次結束後仍只顯示最近 20 次，不需要新增第 21 個結構，也不算遺失必要欄位。
3. 容易誤判的地方
沒有進行中的測試而送 STC=Fh 不修改 Log，不能要求插入「中止成功」的新測試結果。
用 DSTC、DSTR、POH 與診斷內容比較前後快照，避免只用可能重複的時間值辨識唯一測試。
來源：Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.7.1–3.7.4 · 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 的文件頁碼等於 PDF 頁碼減 26；NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題，只引用本題需要的定義，不納入 Fabrics 或 PCIe Link、封包內容。
- Base 2.4 · §3.7.1–3.7.4
文件頁 120–124 · PDF 146–150 - Base 2.4 · §4.2.3
文件頁 145–155 · PDF 171–181 · Figure 101–105 - Base 2.4 · §5.2.2
文件頁 183–190 · PDF 209–216 · Figure 150–156 - Base 2.4 · §5.2.2 (PCIe-applicable events)
文件頁 183–191 · PDF 209–217 · Figure 150–160 - 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.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.14.2.1
文件頁 340–387 · PDF 366–413 · Figure 338–341 - NVM Command Set 1.3 · §4.1.4.3
文件頁 75–76 · PDF 75–76 · Figure 111
需要看欄位圖時
以下連結可開啟對應的圖表教學，查閱欄位及判讀方式。每張圖保留固定的教學位置，方便之後反覆查詢。
- Base 2.4 Figure 101 · Completion Queue Entry: Status Field
- Base 2.4 Figure 104 · Status Code – Command Specific Status Values
- Base 2.4 Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
使用的原始文件
- 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
Comments