整合驗證與證據交叉比對

1. 先保留哪些證據

先固定同一 controller、命令集、namespace 與測試時點，避免拿另一條路徑的能力來比。

保存 Identify 的支援位元與 Effects.CSUPP，並記錄 CSI／UUID 選擇。

CSI

Command Set Identifier，命令集識別碼

假設支援 Format，卻回 Invalid Format；先讀原命令的 LBAF 與 namespace 可用格式。

2. 依什麼順序排除原因

先檢查實際 SCT／SC，而不是只看應用程式顯示的「失敗」。

SCT

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

先解 CQE，再逐項核對參數、namespace 狀態、Write Protection 與當時的管理操作限制。

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

若只因選到不支援的 LBA Format 而失敗，這可與「支援 Format」完全一致。

LBA

Logical Block Address，邏輯區塊位址

若所有前提成立卻回 Invalid Opcode，才進一步核對命令集及支援宣告是否矛盾；單次失敗不能直接定案。

以同時點、單一變因的合法對照命令驗證，避免用另一組不同參數的成功取代原問題。

1. 先保留哪些證據

先確認欄位確實適用於這個 controller 類型、命令集與查詢版本。

對照 Identify、Supported Log Pages 或 Commands Supported and Effects 的對應宣告，不混用不同能力欄。

例如 Effects 中某 opcode 的 CSUPP=0，但相同 CSI 下合法命令完成且有實際效果，兩項證據需要調查。

2. 依什麼順序排除原因

先檢查查詢 selector 與命令 selector 是否一致。

先排除舊快照、Firmware Activation、錯誤 opcode 分類與誤解保留欄位，再重做同時點查詢。

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

宣告應與當前支援一致；驗證要同時看回覆與可觀察結果，避免假的 Success 沒做事。

只有規範要求不支援時拒絕，才能指定對應錯誤；不能把未知／不適用欄位清零一概當成禁止命令。

若確認同一合法條件下宣告與執行矛盾，保留兩份原始回覆，指出違反的具體欄位規則。

1. 先保留哪些證據

Feature 可能屬於 controller、namespace 或其他實體，Get 必須指定相同目標。

查 SEL=3 的能力與該 FID 的欄位定義，確認是否允許 controller 調整要求值。

FID

Feature Identifier，功能識別碼

例如 KATO 可依 KAS 向上調整，讀回值大於要求不必然是錯誤；不能只做逐 bit 相等比較。

2. 依什麼順序排除原因

FID

Feature Identifier，功能識別碼

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

若讀的是 Default 或另一 NSID，先修正查詢；若 selector 都相同且沒有允許調整或並行修改，才定位 controller 不一致。

保存中途的其他 Set、reset、模式切換；它們都可能使測試後的 Current 不同。

1. 先保留哪些證據

讀取範圍與事件的 controller、namespace 或 Group 必須相符。

保存 AER.CQE.DW0 的事件分類、資訊與 LID，並核對所需額外 selector。

LID

Log Page Identifier，紀錄頁識別碼

例如溫度越過門檻後又恢復，SMART Current Warning 可能已清除；這不否定稍早通知。

2. 依什麼順序排除原因

先檢查 LID、scope 與事件至讀取之間的時間差。

LID

Log Page Identifier，紀錄頁識別碼

先讀正確 Log，再查其他 Host 或程式是否已用 RAE=0 確認，及 Log 是否在兩次讀取間變動。

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

事件資訊、讀取時間與目前狀態能形成合理時間線，即使目前警告已消失也可能正常。

Immediate、One-Shot 與一般事件清除方式不同；不能要求每種事件都必須留在 Log 等 Host 讀。

若事件與 Log 持續矛盾，保存首次讀取原件與所有 RAE 操作，避免重讀把證據改掉。

1. 先保留哪些證據

以同一 controller 的命令與 Error Count 比較；短時間多個錯誤可能覆蓋舊 entry。

查 CQE.More、錯誤類別與該命令專屬的補充記錄要求。

More=1 指出有額外狀態資訊；More=0 不能反推絕不記錄。

2. 依什麼順序排除原因

先找出這一個錯誤的 shall／should／may 記錄要求。

保存失敗前後的 Error Count 與所有有效 entries，再依 SQID／CID／Status 關聯。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

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

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

若該類錯誤不強制新增且沒有其他違反條件，沒有新 entry 可以合規。

若命令明定必須寫 Error Information 補充資訊，例如特定容量不足條件，缺少記錄就不能用一般可選規則帶過。

排除 ring 覆蓋、重設清除與錯誤讀取長度後，才判斷記錄是否真的缺失。

4. 用 Log 補充哪些證據

成功 CQE 不會單憑成功這件事，就要求新增 Error Information entry。 完整條件見本冊說明

1. 先保留哪些證據

CQE 屬於一筆命令，Error entry 補充錯誤，PEL 描述持續事件及其影響範圍。

查事件支援、More 與原始命令身分，確認比較的是同一件事。

Error Status 的 15:1 應與相符 CQE Status 相同；Phase 可有其規範允許處理，不應當作錯誤碼的一部分。

2. 依什麼順序排除原因

先確認三份紀錄各自能證明什麼，而不是先找相同文字。

先關聯 controller、SQID、CID 與時間，再解析 PEL 的事件專屬欄位，例如 Format 的 INFO／FNVMS。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

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

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

Sanitize 命令成功接受，但稍後操作失敗時，早先 Success CQE 與失敗完成事件可以同時正確。

若把不同時間的同 CID 或 PEL 請求值當成完成值，會形成假矛盾；真正違規需指明同一欄位關係的要求。

建立含「接受、開始、操作完成、查詢」的時間線，再逐欄比對。

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

先判斷 Feature scope 與 reset 實際涵蓋的物件，部分重設和整體重設可能不同。

保存 Supported Capabilities、Current、Saved 與 Default，以及最後一次成功 Set 的 SV。

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

例如 Namespace Write Protection 具有專屬持續性，不能只因不可保存就要求 CLR 清除。

先用成功 Set 建立已知 Saved，再執行明確 reset 類型，恢復後查同一目標的 Current／Saved。

恢復值符合一般 Feature 規則及個別例外才通過，不以「所有值變 0」當成功。

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

若 Set.SV 未成功或中途另有合法 Set，就不能把差異直接歸為保存遺失。

將每個 FID 的保存與持續性分欄，並記錄 reset 來源和範圍。

先檢查成功 Set 的 SV 與該 FID 的例外。

1. 先保留哪些證據

同一 namespace 的變更不一定讓每台 controller 看到相同清單；需看各台 attachment 與通知規則。

查支援、AEC 與等待中的 AER，再保存管理命令前後的清單。

Attach 後看 Active List，Create 後看 Allocated List；兩者不能互相代替。

2. 依什麼順序排除原因

先確認此次變更是 Create／Delete 還是 Attach／Detach。

以單一操作建立時間線，等命令完成，再讀事件與清單，最後重讀 Identify 確认目前結果。

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

Changed List 有 NSID 並不表示該 namespace 目前仍存在；Delete 也能讓 Host 需要更新舊資訊。

清單超量可用 FFFFFFFFh 表示無法逐一列出，此時應重新探索全部，不把它當成真實 NSID。

先保存首次清單讀取，並區分管理命令所在 controller 與其他被通知 controller。

1. 先保留哪些證據

Firmware 的 slot 與啟用可由同 Domain 的 controllers 共用，查詢必須在相關範圍內。

查 FRMW、LID03h 的 CAFS／NAFS／FRS，以及 Identify.FR。

保存 Commit Action、Slot 與 CQE；某些結果要求 CLR、Subsystem 或 Conventional Reset，不是任意 reset 都能替代。

2. 依什麼順序排除原因

先檢查 Commit Action 與是否做了正確類型的啟用。

先確認 Commit 有效，再執行指定啟用步驟，恢復後讀 FR 與目前 slot。

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

若新映像版本字串與舊版相同，FR 沒變不證明沒啟用；還需 slot 與其他可靠版本證據。

啟用失敗可回復可用映像；PEL 的 New Firmware Revision 是要求的新版本，不自動證明已成為目前版本。

把 pending slot、active slot、實際 FR 與 Firmware Commit／Reset 事件分開核對。

1. 先保留哪些證據

先分 Subsystem 與 Namespace Sanitize，並查正確 NSID 的結果。

查 SANICAP、命令類型、Sanitize Status 及支援的完成事件。

SPROG 是進度，SOS 是操作狀態；不能只看到 SPROG=FFFFh 就忽略 SOS 與 verification state。

2. 依什麼順序排除原因

先檢查你稱為「完成」的證據到底是哪一種。

保存啟動 CQE，持續查狀態；有完成 AER 時再查相同操作的最終結果。

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

啟動成功後 SOS=進行中可以正常；真正完成時才應切換相應完成狀態並符合事件／Log 順序。

若已確認同一操作完成，Log 卻持續顯示進行中，先排除新的 Sanitize、錯誤 scope 或舊快取回覆。

比對命令、Log、AER 及 PEL 的同一次操作，分清「命令完成」與「清除完成」。

1. 先保留哪些證據

確認查同一 controller／共享操作範圍，並使用正確的 Log 版本與完整長度。

查 OACS、DSTO、EDSTT 與 LID06h；結果最新在前，有 20 筆結果位置。

Current Operation、Completion Percentage、DSTR、DSTC 與 VDINFO 分別描述進行狀態、結果及欄位有效性。

2. 依什麼順序排除原因

先確認真的曾啟動測試，而非只成功送出 idle Abort。

保存開始前結果，啟動一次測試，等 Log 顯示結束，再與最新結果比對。

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

規範要求結果更新與 Current Operation 回到 idle 的順序一致；讀到 idle 時應能查到本次應記錄的結果。

Idle 時送 Abort 可成功但不新增結果；不能把這種情況誤判為漏記一次測試。

Short 遇 CLR 會中止，Extended 具有不同持續性；用測試種類與中斷時間解釋結果代碼。

1. 先保留哪些證據

Base2.4 使用 Unexpected Power Loss Count（UPL）；它是裝置記錄的失電事件，不是 Host 呼叫 Shutdown 的次數。

保存 SMART 計數、CC.SHN、CSTS.SHST 及實際失電時點。

一般條件為主電源移除時 SHST 尚未 10b；適用的帶外 Ignore Shutdown 情況另看媒體是否仍活躍。

2. 依什麼順序排除原因

先確認主電源是否真的移除，以及當時 SHST 是否已 10b。

先讀基準計數，發出 shutdown，觀察狀態，再於指定時點斷電，恢復後比較。

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

Abrupt 也可能達到 Shutdown Complete 後才失電，因此不能要求每次 Abrupt 都增加 UPL。

Normal 要求若尚未完成就掉電，仍可能計數增加；沒有失電的 controller reset 也不能自動算一次。

比對真正失電前最後狀態，避免使用重啟後 SHST 的值倒推。

1. 先保留哪些證據

SMART 整體警告與 Group-specific 警告要用各自 scope 與設定。

確認 AEC 對應位元、支援能力、是否有 outstanding AER，以及舊同類事件是否尚未確認。

保存變化前後 CW、溫度／spare 等原始值及門檻；不要只保存應用程式的警告文字。

2. 依什麼順序排除原因

先確認事件發生時的 AEC，而不是事後才讀到的設定。

先確認達到事件條件，再查 AER 是否被其他事件占用或通知被合併，最後檢查相關 Log 的 RAE 讀取。

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

已啟用且符合條件的事件，應依該類型排隊與回報規則被處理；不一定每次取樣變動都另完成一筆 AER。

如果沒有等待中的 AER，不能要求當下就有 CQE；同樣地，不應把未處理 CQE 誤判成 controller 沒通知。

將 CW 時間線、AEC、AER 清單及 RAE 操作放在一起，找出真正缺少的一步。

1. 先保留哪些證據

PEL 為 subsystem 範圍，多個 controller 的事件可能交錯，也可能受供應商允許的排序影響。

查目前報告 context、Generation Number 與 Timestamp Origin／SYNC。

Timestamp 可因 Host Set、reset 或 saved-value 恢復而跳變；不能把它一律當嚴格遞增序號。

2. 依什麼順序排除原因

先確認是否讀了同一份 context 與正確事件邊界。

先在同一 context 讀完整事件，依 EHL／EL 正確走訪，再用 Timestamp Change 與 Reset 事件解釋時間變化。

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

規範建議新到舊排列，但允許供應商定義的事件順序；測試不能把 should 改成絕對排序要求。

若分段讀取混用不同 context，或把 EL 不含 vendor bytes 來算，可能產生假的亂序或壞事件。

用 Host 單調時間保存提交與完成，作為比對線索，但不要求它與未同步的裝置時計完全相等。

1. 先保留哪些證據

先判斷這是一般 controller，還是正處 Offline 的 secondary；後者也會設定 CFS。

保存 CC、CSTS、CAP、VS、可存取的設定資訊與近期管理操作。

若通道仍允許，讀 Error、SMART、PEL 或先前已存在的 Telemetry；不保證每個 CFS 原因都有專用可讀紀錄。

2. 依什麼順序排除原因

先確認 controller 角色與目前 Register 讀取是否可信。

先留存最小原始證據，再依裝置可用狀態做 reset 與恢復，之後補查持續性紀錄。

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

恢復後重新初始化及探索，確認 CFS 不再阻止服務；舊命令結果仍需按中斷的不確定性處理。

若 MMIO 無法可靠讀取，就不能把全 1 或預設值直接解析成真實 NVMe 狀態。

MMIO

Memory-Mapped I/O，記憶體映射輸入輸出

分開 controller 回報、Host timeout 與通訊失效的證據，避免將其中一項代替全部原因。

1. 先保留哪些證據

使用 controller、SQID、CID 與 queue 使用期間識別每筆命令。

保存 Abort 指定的 SQID／CID、Abort 自己的 CID 及 CQE.DW0.IANP。

IANP=0 表示 Abort 已達成規定的立即中止效果，但目標命令仍須依其完成規則結束，不能因此省略目標命令的 CQE。IANP=1 則表示沒有取得這項立即效果，目標命令之後仍可能正常完成。

2. 依什麼順序排除原因

先檢查兩筆 CQE 的 SQID／CID，哪一筆其實屬於 Abort。

先分出 Admin Abort CQE 與原 I/O CQE，再檢查 Host 是否因 Phase 或 Head 錯誤讀了同一筆兩次。

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

正常情況可以是一筆 Abort CQE 加上一筆目標命令 CQE，Host 應將兩者分別對回各自的命令。目標命令可能已經修改部分資料，因此看到 Abort 完成後，不能直接假設原命令完全沒執行而原樣重送。

若已排除 Host 重複讀取同一 CQE，也確認 CID 沒有重用，controller 卻仍對同一次提交的目標命令產生兩筆有效 CQE，才是同一命令被完成兩次的問題。

CID 重用與 CQ 繞回必須排除，不能只憑兩張截圖顯示相同 CID 就判重複。

CQ

Completion Queue，完成佇列

1. 先保留哪些證據

先限定是被刪除 SQ／CQ 本身，還是其他仍有效命令的 buffer；兩者不能混為一談。

SQ

Submission Queue，提交佇列

CQ

Completion Queue，完成佇列

保存 Delete 的目標 QID、成功 CQE 與 queue 記憶體位址範圍。

刪 SQ 與刪 CQ 的依賴及完成要求不同；提交 Delete 不代表已成功結束使用。

SQ

Submission Queue，提交佇列

2. 依什麼順序排除原因

先確認成功 Delete CQE 已經完成，而非命令還在 outstanding。

先等刪除成功，再判斷觀察到的存取是否確實來自該 queue，排除位址被新 queue 合法重用。

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

成功回收後，controller 不應再把該範圍當成已刪除 queue 使用。

若仍有這類存取，可能覆寫 Host 資料、使用錯誤命令或產生無法關聯完成，不能以一般 timeout 掩蓋。

保留位址重用時間與新舊 QID 對照；只有位址相同仍不足以證明舊 queue 在存取。

1. 先保留哪些證據

Reset 結束受影響 queue 的舊使用期間，新 queue 即使沿用位址與 QID 也屬於新的期間。

查 reset 來源、RDY 變化、CQ 初始化與 Host 期待的 Phase。

Host 重建 outstanding map，將舊命令與新命令分開；不能用相同 CID 自動配到新請求。

2. 依什麼順序排除原因

先檢查新 queue 的 Phase 與命令追蹤是否重新初始化。

先完成 reset 與記憶體初始化，再啟用新 queue；只處理新使用期間中有效的 CQE。

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

殘留的舊 CQE 不作正常新完成處理；中斷前操作是否已修改媒體，另用操作結果與恢復規則判斷。

如果 controller 在重設完成後仍主動寫入舊 queue，需按生命週期違規調查；單純殘留 bytes 不足以證明它做了這件事。

用記憶體初始化前後與寫入時點分辨殘留、Host 重複處理及真正晚到的存取。

1. 先保留哪些證據

Detach 影響指定 controller 的 attachment，其他仍 attached 的 controller 可以保留存取。

讀該 controller 的 Active List 與 namespace 的 Attached Controller List，確認操作真的完成。

分清一般 I/O、allocated-namespace Identify 與其他有特殊 NSID 規則的管理命令。

2. 依什麼順序排除原因

先確認命令送到哪台 controller，以及命令種類是否真的需要 active namespace。

先等 Detach 成功，再送全新的命令到被移除的路徑；不要拿 Detach 前已完成的 CQE 來比較。

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

另一條仍附加路徑的 I/O 成功可以正常；查 allocated 資料也可能合法。

對已 inactive namespace 的一般適用命令，若無例外應回 Invalid Field；invalid NSID 則是不同條件的 Invalid Namespace or Format。

Outstanding 命令依 Detach 與各命令規則處理，測試要分開操作前後提交的命令。

1. 先保留哪些證據

CSEL、CNTLID、IFC 與 SCP 共同決定目標，不能只記 opcode。

先讀 Lockdown 支援與適用的目前禁止清單，使用相同 UUID、介面及 controller 選擇。

SCP 指 Feature 時限制 Set Features，不自動禁止 Get；增強 FFFFh 彙整的 ACNTL=0 也不代表無人受限制。

2. 依什麼順序排除原因

先檢查 IFC／CSEL／SCP，而不是只看功能名稱。

確認 Lockdown 成功後，對完全符合 selector 的目標重試；同時設一個應允許的對照命令。

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

匹配的被禁止 Admin command 應回 Command Prohibited by Command and Feature Lockdown（0/23h）。

先排除 Power Cycle 解除、後續允許操作、不同介面或 personality 的明文例外，再判斷執行成功是否矛盾。

比對 Lockdown CQE、清單與目標命令行為，三者必須使用同一組選擇條件。

1. 先保留哪些證據

先確認來源與目標 Power State，以及當時是否受 thermal management 等其他條件影響。

查 PSD 的 NOPS、ENLAT、EXLAT，及 Power Management／APST 設定。

APST

Autonomous Power State Transition，自主電源狀態轉換

APST.ITPT 是閒置等待時間，單位 ms；ENLAT／EXLAT 是轉換延遲，單位µs，不能相加前忘記換算。

APST

Autonomous Power State Transition，自主電源狀態轉換

2. 依什麼順序排除原因

先確認單位及計時起點。

記錄最後一次活動、進入省電狀態、觸發退出及恢復處理命令的時間。量測轉換延遲時，應將命令本身的執行時間分開，避免把媒體讀取時間也算成退出省電狀態的時間。

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

例如從非工作狀態回到前一工作狀態，按相關退出與進入延遲判斷，而不是把完整 Read 完成時間等同 EXLAT。

若只有 CQE 時間而無法分辨內部狀態切換，證據不足以單獨證明 EXLAT 違規。

用同 workload 的工作狀態基準、溫度與設定快照做比較，說明仍無法排除的因素。

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

Controller Level Reset、Subsystem Reset 與 Power Cycle 的範圍及持續性條件不同。

先選一個明確功能，保存其能力、Current／Saved、Log 與涉及的其他 controllers。

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

分欄記錄 Register、queue、設定值、操作是否持續及儲存資料；不要把全部寫成單一「保留／不保留」。

每次恢復相同初始條件，只改 reset 類型；完成後先恢復查詢通道，再檢查各欄。

例如 Extended Self-test 可在 CLR 後持續，但 I/O queues 仍失效；兩個結果可以同時成立。

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

CC.EN reset 的 Register 保留例外不能套用到所有 CLR；同樣，Subsystem Reset 不是 Restore Defaults。

每個差異都連到明確規則，未定義的行為標示證據界線，不猜一個統一答案。

先把 reset 的實際觸發方式寫清楚。

1. 先保留哪些證據

作用範圍可能是 namespace、controller、Group、Domain 或 subsystem，需由命令與欄位共同決定。

查命令欄位、Feature scope、Identify 的能力及 Commands Supported and Effects 的相關資訊。

NSID=FFFFFFFFh 的意思因命令而異；Effects 未回報某 scope 也不能取代命令的明文定義。

2. 依什麼順序排除原因

先讀該命令對 selector 的定義，特別是 0 與 FFFFFFFFh。

列出提交端、目標與共用資源，再選一個範圍內及一個範圍外對照物件觀察。

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

例如 Detach 指定一台 controller，而共享 namespace 資料並未因此複製或刪除。

對範圍外物件的變化，先排除共用資源與同時發生的另一操作，再判是否超出規範。

比較使用相同物件 ID 與穩定時點；不同 controller 的 Active List 本來就可能不同。

1. 先保留哪些證據

先界定功能與受影響物件，避免一次測多個功能而無法分清哪個造成差異。

保存 Identify、Supported／Effects Logs 與需要的 Feature 設定作為基準。

保存原命令及 selector、CQE、相關 Log、AER 與 PEL；不適用或不支援的介面明確標記理由。

2. 依什麼順序排除原因

先寫出這次要驗證的一條具體規範要求，再決定需要哪些證據。

先做合法正常案例，再一次只改一個非法參數或順序；最後從相同基準分別驗證 reset 與 Power Cycle。

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

結論能指出哪個規範要求被哪些觀察支持，以及哪些資料仍不足以判斷。

禁止把 may 當 shall、把未定義行為指定為固定 Status，或用「命令成功」省略背景操作最終結果。

用一張時間線串起原始資料，保留規格章節、Figure 與 PDF 頁碼，讓另一位讀者能重走推理。