NVMe · Q1–328

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

Q107–Q117

Abort、Timeout 與錯誤恢復

Timeout 是 Host 的觀察，未必能說明命令停在哪裡。本冊沿提交、取得、執行、完成與處理的路徑找證據，再決定 Abort 或較大範圍 reset。

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

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

先確認命令走到哪一步

未看到完成，不代表命令沒有執行，也不代表媒體沒有變動。

可觀察階段主要證據下一個疑點
已提交SQE、Tail DoorbellController 是否取得
已取得適用的 SQHD 與追蹤資料是否正在長操作
已完成CQE 與 PhaseHost 是否漏處理
恢復中Abort CQE／reset 狀態原操作結果是否仍不確定
SQE
Submission Queue Entry，佇列中的命令項目
CQE
Completion Queue Entry，佇列中的完成項目

舉例看懂：Abort 指向 SQ5/CID9，Abort 本身是另一筆 Admin command。兩者各回一筆 CQE 可以正常；只有同一目標命令真的完成兩次，才是重複完成問題。

來源：Base 2.4 §5.2.1 · 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 §4.2.1, 4.2.3–4.2.4

先把觀念接起來

教學 1 · 先分清三種時間

Ready Timeout 用於 controller 狀態切換，Host 的 Command Timeout 用於軟體等待，而長時間管理操作另有其進度與限制。把這三者套同一秒數，可能將正常 Sanitize 或 AER 判成故障。每次量測都要寫下起點、等待的條件及規範是否真的給了上限。

教學 2 · Abort 不是撤銷交易

命令在被中止前可能已產生部分效果。即使 Abort 有立即效果，也不能保證把已寫資料回復成舊內容。Host 應先保留目標命令與結果的不確定性，再決定是否能安全重試；對有副作用的管理操作，重新查目前狀態尤其重要。

教學 3 · 恢復範圍要跟問題相稱

一筆命令卡住不一定需要整個 subsystem reset，但通道已無法使用時，繼續送 Abort 也可能沒有幫助。先判斷 CQ 是否滿、命令是否已完成但 Host 漏看，以及 Admin 通道是否可用。選擇較大範圍 reset 後，必須一起重建該範圍內的 queues 與命令追蹤，不能只重送原命令。

CQ
Completion Queue，完成佇列
需要時回顧本篇名詞
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. Q107 · Abort 如何用 SQID 與 CID 指定目標？
  2. Q108 · Abort 已完成、不存在或指定錯誤 SQID／CID 的命令時會怎樣？
  3. Q109 · 重複 Abort 與並行 Abort 如何套用 ACL？
  4. Q110 · Abort 成功是否代表目標完全沒有執行？
  5. Q111 · Abort 未立即中止時，目標還能正常完成嗎？
  6. Q112 · Abort 與目標完成同時到達，Host 如何避免重複處理？
  7. Q113 · Timeout 後一定要依 Abort、Queue Reset、Controller Reset 的順序嗎？
  8. Q114 · Abort 本身也 Timeout，Host 應如何復原？
  9. Q115 · Reset 後如何處理舊命令、舊完成與舊 Queue？
  10. Q116 · 如何區分 Command Timeout、Ready Timeout 與長時間操作？
  11. Q117 · Timeout 時如何定位提交、取得、執行、完成或 Host 處理階段？

Q107 Abort 如何用 SQID 與 CID 指定目標？

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

Abort 請求中止一筆先前提交的命令，讓 Host 不必只為一筆逾時操作立即重設整個 controller。它是請求，不是保證目標尚未執行。

1. 操作前先準備什麼

目標可以位於 Admin SQ 或 I/O SQ。Abort 自己也是 Admin 命令，有自己的 CID 與完成結果。

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

Identify.ACL 宣告可同時 outstanding 的 Abort 數量，零起算；一般命令的 queue 深度不能代替 ACL。

Abort CDW10 bits31:16 是目標 CID，15:0 是目標 SQID；Abort 自己的 CDW0.CID 則用來配對 Abort 的 CQE。

SQID
Submission Queue Identifier，提交佇列識別碼

2. 先後順序與完成條件

從 outstanding 清單找到目標 SQID／CID，保留目標的 buffer，再以新的 Admin CID 提交 Abort；分別追蹤兩筆完成。

Abort 成功 CQE 的 DW0.IANP=0 表示立即中止已執行；IANP=1 表示未執行立即中止，仍可能稍後中止。最後也要查看目標 CQE。

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

超過 ACL 時，controller 可回 Abort Command Limit Exceeded（1/03h）。目標找不到則可由成功 Abort 的 IANP=1 表示，不應固定要求 Invalid Queue Identifier。

模擬 SQ3／CID7 與 SQ4／CID7 同時存在時，CDW10=(7<<16)|3 只指定前者。用這個例子驗證解析是否把兩個欄位顛倒。

來源：Base 2.4 §5.2.1 · Base 2.4 §4.1.1 · Base 2.4 §5.2.14.2.1 · 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.1 · Base 2.4 §4.1.1 · Base 2.4 §5.2.14.2.1 · 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)

回本冊題目

Q108 Abort 已完成、不存在或指定錯誤 SQID／CID 的命令時會怎樣？

跟著解說理解

目標在 Host 決定中止與 controller 處理 Abort 之間可能已完成，所以「沒找到」是必須處理的正常競爭情況。

1. 先區分是哪一種失敗

判斷的是指定 SQID／CID 在那個時點的命令，不是 Host 曾經提交過同一編號就永遠存在。

讀 Abort 的 CQE Status 及 DW0.IANP，並檢查目標是否已留下有效 CQE。IANP=1 的原因可以是找不到目標，也可以是無法立即中止。

不要把所有不存在的 SQID／CID 都要求成某個固定錯誤 Status。若 Abort 本身欄位另有非法值，則依該非法條件處理。

2. 用哪些資料確認原因

保留 queue 使用期間與 CID 配置紀錄，避免 Abort 延遲到 CID 已被下一筆命令重用。

先處理已收到的目標完成，再處理 Abort 結果；如果目標仍 outstanding 且 IANP=1，繼續追蹤目標，不能擅自釋放 buffer。

3. 結果與後續驗證

有效的 Abort 命令即使沒中止目標，也可回成功且 IANP=1。這表示請求處理完成，不是目標操作成功或回復。

如果測試期待「目標已完成後 Abort 必須失敗」，應修正為核對 IANP 與既有目標結果。

先查目標是否其實早已完成，只是 Host 尚未消費 CQE。

來源：Base 2.4 §5.2.1 · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · 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.1 · Base 2.4 §4.2.3 · Base 2.4 §3.7.1–3.7.4 · 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)

回本冊題目

Q109 重複 Abort 與並行 Abort 如何套用 ACL？

跟著解說理解

ACL 限制同時處理的 Abort 請求數量，不是每秒可中止多少命令，也不是可被中止的 namespace 數。

1. 先區分是哪一種失敗

每一筆尚未完成的 Abort 都占用其並行配額；多筆指向同一目標，也不能當成只送了一筆。

分開記錄 Abort 自己的 Admin CID、目標 SQID／CID 及結果。大量中止可考慮支援的 Cancel，或刪除並重建 I/O SQ。

controller 可將超額請求完成為 Abort Command Limit Exceeded（1/03h），規範不是要求每個超額時點都必定看到此碼。

2. 用哪些資料確認原因

Identify.ACL=0 表示支援至少 1 筆並行 Abort；ACL=3 表示 4 筆。Host 應依完成回收這份配額。

提交前檢查配額，達上限就等待先前 Abort 完成。重複目標時仍逐筆處理 Abort CQE，但目標命令不能因此完成兩次。

3. 結果與後續驗證

例如 ACL=1，兩筆 Abort outstanding 符合配額；其中一筆完成後才提交下一筆，就不會因 Host 超量造成干擾。

測量 outstanding 數時，以提交到完成的期間計算；不要拿累計 Abort 次數與 ACL 比較。

先確認測試是否漏掉 ACL 的零起算，或重複計入已完成的 Abort。

來源：Base 2.4 §5.2.1 · Base 2.4 §5.2.14.2.1 · 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.1 · Base 2.4 §5.2.14.2.1 · 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)

回本冊題目

Q110 Abort 成功是否代表目標完全沒有執行？

跟著解說理解

不代表。Abort 能停止後續處理，卻不是交易回復機制；目標可能在中止前已傳輸部分資料或改變狀態。

1. IANP 決定的是中止後的保證

Base 2.4 的關鍵證據是成功 Abort 的 IANP，而不是單看 Status=Success。

IANP=0 時，除之後張貼目標 CQE 外，Abort CQE 張貼後不得再有目標命令造成的 Host memory 存取或媒體／管理狀態改變。

立即中止後，目標以 Command Abort Requested 完成。目標 CQE 可在 Abort CQE 之前，也可在滿足無後續效果條件下之後出現。

IANP=1 不保證無後續效果；如果資料傳輸已開始而未完成，且目標 CQE 尚未張貼，就不能宣稱符合立即中止條件。

2. 已經發生的效果仍要另外確認

記錄 Abort CQE 時點及 IANP，等待並處理目標 CQE，再依命令語意確認資料結果。若需重試 Write，先處理可能已執行部分與重試的關係。

合規測試應檢查 Abort CQE 之後是否仍有被禁止的目標效果，而不是要求整個命令從來沒有做過任何事。

來源：Base 2.4 §5.2.1 · Base 2.4 §3.4.1–3.4.5 · 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.1 · Base 2.4 §3.4.1–3.4.5 · 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)

回本冊題目

Q111 Abort 未立即中止時，目標還能正常完成嗎？

跟著解說理解

可以。IANP=1 表示未執行立即中止，controller 仍可稍後中止，也可能讓目標正常完成。Host 必須保留兩種可能。

1. 先分開判讀 Abort 與目標的 CQE

查看成功 Abort 的 IANP 及目標 CQE。若 Abort 自己以錯誤完成，不應把保留或未定義的 DW0 當成有效 IANP 結果。

目標若延後被中止，Status 必須是 Command Abort Requested；若正常執行完成，則依目標命令回報實際結果。

收到目標成功 CQE 是合法可能；收到 Command Abort Requested 也是合法可能。兩者都不需要再產生第二筆目標完成。

2. IANP=1 後仍要追蹤目標

IANP=1 後持續等待有效目標 CQE，同時依 Host 復原策略控制等待時間。若需要擴大到 Reset，先完成 queue 使用期間的切換與資源保護。

不要將 IANP=1 解釋成「永遠不會中止」，也不要解釋成「一定晚一點中止」。

來源：Base 2.4 §5.2.1 · 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.1 · 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)

回本冊題目

Q112 Abort 與目標完成同時到達，Host 如何避免重複處理？

跟著解說理解

並行完成會讓 Host 的 timeout 路徑與一般完成路徑同時碰到同一份追蹤資料。需要同步的是 Host 狀態，不是要求 controller 將所有完成排成固定順序。

1. 操作前先準備什麼

一筆 Abort 與一筆目標命令有各自的生命週期；共享目標不代表兩個 CQE 是同一個完成。

用 CQE.SQID＋CID、有效 Phase 與 queue 使用期間識別命令；只比 CID 不足以跨 queue 關聯。

追蹤資料要能表示目標未完成、已完成，以及 Abort 尚未完成／已完成。只有目標結果才能交付目標的上層完成。

2. 先後順序與完成條件

收到任一 CQE 時，以同步方式更新相應狀態。目標先完成就保存結果，之後 Abort CQE 只結束 Abort；Abort 先完成則依 IANP 與目標狀態繼續處理。

每筆命令各完成一次，每份資源各回收一次。兩個不同命令的 CQE 都存在是正常，不能誤算成目標完成兩次。

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

不能固定要求目標 CQE 一定先於 Abort CQE；Base 2.4 在滿足立即中止的無後續效果保證時，允許任一張貼順序。

驗證同一 target SQID／CID 沒有被上層完成兩次，且新的 CID 使用期間不會吃到舊 Abort 的結果。

來源：Base 2.4 §5.2.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.3.1 · 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.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.3.1 · 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)

回本冊題目

Q113 Timeout 後一定要依 Abort、Queue Reset、Controller Reset 的順序嗎？

跟著解說理解

沒有適用於所有命令的固定三步程序。Host 要先判斷是單筆命令太慢、queue 失效，還是 controller 已無法通訊，再選擇能解決問題的範圍。

1. 先保留哪些證據

Abort 針對命令；I/O queue 刪除／重建針對相關 queue；Controller Reset 會影響該 controller 的全部 queue 與未完成命令。

保存 CQ 指標、Phase、中斷設定、CSTS 與其他命令的進度。CAP.TO 不代表每條 I/O 的 timeout。

CQ
Completion Queue，完成佇列

可用操作包括 Abort、Delete I/O SQ／CQ、重新建立 queue，以及 CC.EN 觸發的重設；每種操作都需要有效的前提與完成確認。

2. 依什麼順序排除原因

先定位失效範圍，再選復原方式

下列分支是 Host 選擇復原範圍的判斷方式，不是規格要求每次都走完的固定三步。

  1. 先看 CQ：是否已經有有效 Completion？

    若只是 Host 漏處理或沒有收到中斷，先處理 CQE 並追查通知路徑。

  2. 單筆命令仍未完成，Admin 通道正常

    可考慮針對目標送 Abort，再分別追蹤 Abort 與目標命令的結果。

  3. Queue 受損，但管理通道可用

    按 Delete／Create 規則復原相關 queue，確認舊存取已停止，再交接記憶體。

  4. Admin 嚴重失效，或 Delete 沒有完成

    考慮 Controller Reset；不必先強迫送出一筆已無法完成的 Abort。

沒有 CQE 時，Host timeout 本身沒有 DNR 可讀。復原後仍需確認背景管理操作是否持續，不能只以新 queue 能送命令作為全部完成的證據。

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

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

復原完成應同時建立可用新通道、結束舊命令的後續存取風險，並重新確認可能持續的背景管理操作。

Host 計時器到期不是 controller 回傳的 NVMe Status。不能為「沒收到 CQE」捏造 Timeout CQE，也不能無條件要求先送一筆注定無法完成的 Abort。

測試計畫要標示哪些是 Spec 要求，哪些是 Host 選定的 timeout 與升級策略。

來源：Base 2.4 §5.2.1 · Base 2.4 §9.1–9.6.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · 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.1 · Base 2.4 §9.1–9.6.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · 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)

回本冊題目

Q114 Abort 本身也 Timeout，Host 應如何復原？

跟著解說理解

這時不只目標結果不明，連 Admin 通道是否可完成命令都需要確認。無限追加 Abort 會增加未完成請求，卻不能證明舊命令已停止。

1. 先保留哪些證據

復原可能從單一命令擴大到 controller；應先通知使用這個 controller 的 queue 管理與資源回收邏輯。

檢查 Admin CQ 的 Phase／Head、CSTS.CFS／RDY，以及 Abort outstanding 是否超過 ACL。

保存 Abort 的 Admin CID、目標 IDs、提交時間及已觀察的 CQE。後續 Reset 是另一項操作，不應偽造 Abort 的完成結果。

2. 依什麼順序排除原因

先檢查 Admin CQ 是否已滿或被 Host 停止消費。

先排除 Admin CQ 已有完成但 Host 漏讀。若確認嚴重 Admin 問題，依 Base 9.1／9.5 進行 Controller Reset、等待狀態，再重建操作環境。

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

成功復原後，新命令可以使用新 queue；舊目標是否曾完成其資料效果，仍需依命令與持久化語意判斷。

沒有 Abort CQE 就沒有可解讀的 IANP、DNR 或 More。也不能將 Reset 成功當成目標 Write 從未發生的證明。

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

以 Register 狀態、新 queue 的可用性及持續操作的 Log 交叉確認，不只用「Reset 函式回傳成功」當成全部證據。

來源：Base 2.4 §9.1–9.6.1 · Base 2.4 §5.2.1 · 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 §9.1–9.6.1 · Base 2.4 §5.2.1 · 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)

回本冊題目

Q115 Reset 後如何處理舊命令、舊完成與舊 Queue？

跟著解說理解

Reset 劃分命令與 queue 的使用期間。記憶體內還看得到舊 bytes，不代表它們仍是可用的命令或完成。

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

受影響 controller 的 I/O queues 與未完成追蹤要重建。媒體上的既有資料與獨立背景操作，則有各自的保留或繼續規則。

查看 Reset 類型、CC／CSTS 及 Admin Queue Register 保留條件；不要把清 CC.EN 的例外套到所有 Reset 來源。

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

Host 重設 SQ／CQ 指標與期待 Phase，將新提交與舊追蹤隔離；背景 Sanitize 等另用對應 Log 查進度。

先停止新提交，完成 Reset 的等待與存取停止確認，再建立新 queue，最後恢復 I/O。需要重試時，先分析原命令是否可能已產生效果。

新 queue 只接受新生命週期的有效完成；Host 不再以舊 CID 清單等待已被 Reset 結束的所有 CQE。

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

Reset 通常不是逐筆回傳某個固定錯誤碼。AER 更明定因 Reset 中止時不得回 CQE；其他命令也不能一律要求 Command Abort Requested。

同時驗證新 queue 正常，以及舊 buffer 不再被舊命令使用；僅看新命令成功，無法排除舊命令晚到的存取。

先查 Host 是否重用了舊 Phase 或追蹤資料，造成把舊 CQE 當成新完成。

來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.3.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · 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.3.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · 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)

回本冊題目

Q116 如何區分 Command Timeout、Ready Timeout 與長時間操作？

跟著解說理解

不同等待對象需要不同期限：命令等待 CQE，初始化等待 RDY，背景操作則可能在命令已完成後持續。混用期限會造成不必要的 Reset。

1. 差別在哪裡

Host 命令 timeout 是軟體政策；Ready 等待針對 controller 狀態；Sanitize 等進度則屬指定管理操作的範圍。

觀察 CQE、CSTS.RDY 及操作狀態 Log。AER 沒事件時應保持 outstanding，規範建議不套一般命令 timeout。

2. 如何選擇與確認

停用看 CAP.TO；啟用依 Ready Mode 與 CRTO／CAP 規則；個別功能若宣告預估時間或最大時間，則按其欄位定義使用。

先寫清楚正在等待哪個狀態轉移，再從正確起點計時。例如成功啟動 Sanitize 後，改查 Sanitize Status，不繼續等第二個 Sanitize CQE。

期限內達到指定狀態才是該項等待成功。命令回 Success 與媒體工作完成，可能分屬不同時間。

3. 比較時要保留的條件

沒有全 NVMe 命令共用的 CAP.TO。預估完成時間也不應自動升級成必須遵守的硬性 timeout。

將測試報告中的每個 timeout 註明來源、單位、起算時點與是估計還是上限。

來源：Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.5.3–3.5.4 · Base 2.4 §5.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · 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 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.5.3–3.5.4 · Base 2.4 §5.2.1 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · 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)

回本冊題目

Q117 Timeout 時如何定位提交、取得、執行、完成或 Host 處理階段？

跟著解說理解

沿命令生命週期保存證據，可以把「沒完成」拆成可查的階段，而不急著歸咎韌體執行太慢。

1. 先保留哪些證據

分析一筆目標命令時，也要觀察其 SQ、關聯 CQ、共享向量與其他命令，因為瓶頸可能位於共用資源。

使用 SQE 快照、SQ Tail Doorbell、回報的 SQHD、CQ Phase／Head、中斷設定與 CSTS；這些都是 PCIe NVMe 介面層證據。

SQE
Submission Queue Entry，佇列中的命令項目

SQHD 前進表示已消費位置，不表示每筆命令完成；有效目標 CQE 才提供完成結果；中斷則是通知 Host 查 CQ 的機制。

2. 依什麼順序排除原因

先直接檢查目標 CQ 的期待 Phase 位置；這通常最快區分「尚未回報」與「已回報但未處理」。

依序確認 SQE 對 controller 可見、Doorbell 已更新、CQ 是否有新 Phase、Host 是否消費並更新 Head。若無法觀察內部取得時點，就明確保留這項不確定性。

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

能定位到「CQE 已存在但中斷或 Host 處理遺漏」，就不應再宣稱命令未執行。若只有 Doorbell 證據，也不能宣稱 controller 已取得命令。

這項診斷本身沒有固定 NVMe Status。不同階段的錯誤應保留各自證據，不用一個自創 Timeout Status 取代。

比對同時間的有效 CQE、共享 CQ 空間及中斷遮蔽，排除 Host 端的進度阻塞。

來源：Base 2.4 §4.1.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.3.1 · PCIe Transport 1.4 §3.1–3.4 · PCIe Transport 1.4 §3.5 · Base 2.4 §9.1–9.6.1 · 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 §4.1.1 · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.3.1 · PCIe Transport 1.4 §3.1–3.4 · PCIe Transport 1.4 §3.5 · Base 2.4 §9.1–9.6.1 · 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.1.4 (CAP, VS)
    文件頁 54–59 · PDF 80–85 · Figure 36–37
  • Base 2.4 · §3.1.4 (CRTO)
    文件頁 72–73 · PDF 98–99 · Figure 57
  • Base 2.4 · §3.3.1
    文件頁 88–91 · PDF 114–117 · Figure 73–74
  • Base 2.4 · §3.4.1–3.4.5
    文件頁 101–105 · PDF 127–131 · Figure 80–81
  • Base 2.4 · §3.5.3–3.5.4
    文件頁 109–113 · PDF 135–139 · Figure 84–85
  • Base 2.4 · §3.7.1–3.7.4
    文件頁 120–124 · PDF 146–150
  • Base 2.4 · §4.1.1
    文件頁 139–142 · PDF 165–168 · Figure 92–93
  • Base 2.4 · §4.2.1, 4.2.3–4.2.4
    文件頁 144–157 · PDF 170–183 · Figure 97–105, 109
  • Base 2.4 · §4.2.3
    文件頁 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §5.2.1
    文件頁 181–182 · PDF 207–208 · Figure 147–149
  • 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.13.1.2
    文件頁 218–220 · PDF 244–246 · Figure 212
  • 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
  • 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.1–3.4
    文件頁 9–13 · PDF 9–13 · Figure 3–8
  • PCIe Transport 1.4 · §3.5
    文件頁 13–16 · PDF 13–16 · Figure 9

需要看欄位圖時

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

使用的原始文件
  • 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