NVMe · Q1–328

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

Q82–Q92

Asynchronous Event Request

AER 讓 Host 先留下等待通知的請求，controller 有事件時才完成它。先理解請求、事件、Log 與確認的關係，再處理多事件、遮蔽與重新掛入。

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

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

通知完成後，工作還沒結束

AER 回報事件線索；詳細內容與目前狀態仍要讀相應 Log。

階段Host 或 Controller 動作需要保存的資訊
事前Host 提交 AER請求 CID 與上限 AERL+1
事件發生Controller 完成適用請求Type、Information、LID
查證Host 讀對應 Logselector、RAE 與原始內容
繼續接收Host 重新掛 AER新的 outstanding 請求
CID
Command Identifier，同一提交佇列內的命令識別碼
LID
Log Page Identifier，紀錄頁識別碼

舉例看懂：假設 AERL=3，允許上限是 4 筆。完成一筆後，Host 可補回一筆；不能把已完成但未補掛的請求仍算成可接收下一事件的空間。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.30.1.6

先把觀念接起來

教學 1 · 等待不是故障

一般命令長期不完成可能需要調查，但 AER 的目的就是等待事件。沒有事件時保持 outstanding 可以完全正常。驗證前先確認這是 AER，而不是誤用一般 I/O timeout。AER 也會占用自己的命令追蹤資料，所以 Host 必須正確處理完成與重新提交。

教學 2 · 通知與確認各自解決一個問題

通知讓 Host 知道有事需要查看；確認則告訴 controller 該事件已被處理。若只補掛 AER 卻沒按事件規則確認，同類事件可能仍受遮蔽；若只讀 Log 卻沒補掛，下一事件可能暫時沒有請求可回報。兩個步驟都需要，但具體清除方式仍要依事件類型判斷。

教學 3 · 一次狀態改變不必對應一筆新通知

多次同類事件可能合併，某些警告在讀取前也可能恢復。不要用取樣次數要求同樣數量的 AER。應先固定事件類型、enable、尚未確認狀態與掛入請求數，再檢查規範要求的通知行為；這比單純比較事件與 CQE 的總數可靠。

CQE
Completion Queue Entry，佇列中的完成項目
需要時回顧本篇名詞
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. Q82 · Host 為什麼需要預先送出 Asynchronous Event Request？沒有事件時為何保持 Outstanding？
  2. Q83 · 事件發生後，Host 如何從 AER Completion 取得事件種類與 Log 位置？
  3. Q84 · Host 處理事件後，為什麼需要讀取對應 Log 並重新送出 AER？
  4. Q85 · AER Request 數量超過 Controller 上限時，應如何回應？
  5. Q86 · 沒有掛入 AER 時發生事件，Controller 如何保留與回報？
  6. Q87 · 多個相同或不同事件同時發生時，Controller 如何合併與回報？
  7. Q88 · Asynchronous Event Configuration 如何啟用或遮蔽特定事件？
  8. Q89 · SMART、Namespace、Firmware、Telemetry、Sanitize、Self-test 與 PEL 各有哪些通知條件？
  9. Q90 · Host 讀取 Log 後，事件如何清除或保留？
  10. Q91 · AER 能否被 Abort？Reset 時尚未完成的 Request 如何處理？
  11. Q92 · AER 已完成，但對應 Log 看不到預期資訊時，應如何定位？

Q82 Host 為什麼需要預先送出 Asynchronous Event Request？沒有事件時為何保持 Outstanding？

跟著解說理解

AER 提供 controller 可使用的通知回覆機會。controller 不能在沒有對應 Request 的情況下，任意產生一筆一般 AER completion，因此 Host 先提交 Request，等待日後事件。

1. 機制與適用範圍

每筆 AER 屬於提交它的 controller 與 Admin Queue。它等待的是事件，不是對某個 namespace 執行讀寫。

AER 的命令特定欄位都是 Reserved；Host 仍需分配 Admin SQ 中唯一的 CID。事件發生後，DW0 的 AET／AEI／LID 與必要的 DW1 描述結果。

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

2. 用操作與結果理解

Identify.AERL+1 是同時未完成 Request 的上限。選配通知另查 OAES 與 FID0Bh，不能把 AERL 當成事件種類數。

完成初始化及通知設定後，提交不超過上限的 AER。收到事件時保存回覆，處理並確認事件，再補上 Request，維持可用的通知機會。

沒有事件時長時間保持 outstanding 是正常行為，Host 不應替 AER 設一般命令 timeout。它不需要定期回成功來證明自己仍存在。

3. 容易誤判的地方

超過並行上限時，會涉及 Asynchronous Event Request Limit Exceeded（1/05h）。尚未有事件而未完成，則不是 Command Timeout 的規範錯誤結果。

比對 Host 尚未完成的 AER 數、AERL、通知設定與事件條件，而不是只計算命令已等待幾秒。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.30.1.6 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.30.1.6 · 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)

回本冊題目

Q83 事件發生後，Host 如何從 AER Completion 取得事件種類與 Log 位置？

跟著解說理解

Completion 的成功 Status 只表示 AER 正常完成；真正的通知內容放在命令特定結果中。必須再解析事件欄位，才能知道要讀哪張 Log。

1. 先確認資料的來源與範圍

以 AER 的 SQID 與 CID 找到原 Request，再解讀這個 controller 回報的事件。不能把另一筆普通 Admin 命令的 DW0 當成 AER 格式。

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

支援的事件種類由能力及 Figure 153～160 等事件表定義。先解 AET，再用它選 AEI 的對應表。

2. 欄位、單位與判讀例子

DW0 bits2:0 是 AET、bits15:8 是 AEI、bits23:16 是 LID。DW1 是事件特定參數；若事件沒有定義它，不能自行當成 NSID。

NSID
Namespace Identifier，邏輯儲存空間識別碼

先驗 CQE 的 Phase 與命令身分，再解 SCT／SC。正常 AER completion 才進一步解事件內容，依事件表讀取 Log 或執行對應處理。

CQE
Completion Queue Entry，佇列中的完成項目
SCT
Status Code Type，完成狀態代碼類型

例如 AET=Notice、AEI=Firmware Activation Starting，指向 Firmware Slot Information；它表示開始啟用，不表示新韌體已啟用完成。Sanitize 的事件也要搭配 DW1 的 target 定義。

3. 判讀時要保留的條件

若 AER 本身以 1/05h 等錯誤完成，不能把 DW0 任意解成正常事件。AEI 的相同數值在不同 AET 下也可能代表不同事情。

保存完整 CQE 與後續 Log，核對事件所指的 LID 及 target，而不是只保留翻譯過的一行訊息。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §4.2.1, 4.2.3–4.2.4 · 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.2 (PCIe-applicable events) · Base 2.4 §4.2.1, 4.2.3–4.2.4 · 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)

回本冊題目

Q84 Host 處理事件後，為什麼需要讀取對應 Log 並重新送出 AER？

跟著解說理解

讀取 Log 用來了解並確認事件；重新提交 AER 則提供下一次回報機會。兩個動作目的不同，少做其中一個都可能讓後續通知看似停止。

1. 操作前先準備什麼

一般事件回報後，相關事件類型會被自動遮蔽，直到 Host 按規則確認。Immediate 與 One-Shot 另有規則，不能套用相同清除流程。

確認此事件對應的 LID、RAE 規則與通知啟用狀態。AERL 只限制等待中的 Request，不能解除事件遮蔽。

一般使用 Get Log Page 並以 RAE=0 確認；RAE=1 保留事件。新的 AER 是另一個 Admin 命令，必須有自己的有效 CID。

2. 先後順序與完成條件

事件確認與補上 AER 是兩件事

這是一般需透過 Log 確認的事件路徑；Immediate 與 One-Shot 須另依各自規則處理。

  1. 收到 AER Completion → 保存通知

    先記錄事件種類、資訊與 LID，再讀取所需診斷內容。

  2. 依事件規則確認

    通常以成功的 Get Log Page、RAE=0 確認。RAE=1 是保留；讀取失敗也不能當作已確認。

  3. 維持等待中的 AER

    重新提供 Request，才能接收後續回報；補 Request 本身不會確認上一個事件。

若警告條件持續存在，確認後仍可能再通知。確認前應考慮門檻或通知設定，避免反覆回報；檢查時分開確認「資訊已保存、事件已確認、Request 仍在等待」。

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

讀取失敗時事件必須保留，不能把嘗試過 RAE=0 當成清除成功。若是 One-Shot，則在回報時已清除，應依該事件處理。

檢查三件事是否都完成：事件資訊已保存、確認動作成功、仍有 AER 等待。它們不是同一個成功碼能證明的事情。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.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)

回本冊題目

Q85 AER Request 數量超過 Controller 上限時，應如何回應？

跟著解說理解

AER 上限限制 controller 必須維護的等待命令數，避免 Host 無限制占用回報資源。這個數量與內部可能發生多少事件不同。

1. 先區分是哪一種失敗

上限適用此 controller 同時 outstanding 的 AER，不是整個 subsystem 曾提交過的累計數。

Host 追蹤每個 AER 的 CID、提交與完成時間。已完成的 Request 不再占用 outstanding 名額，補送前須先更新追蹤紀錄。

超過上限的命令對應 Asynchronous Event Request Limit Exceeded（SCT=1, SC=05h）。不要將它與 Abort Command Limit Exceeded（1/03h）混用。

2. 用哪些資料確認原因

Identify.AERL 是 zero-based，實際上限為 AERL+1。例如 AERL=3，最多同時保留 4 筆未完成 AER。

先讀 AERL，再建立不超過上限的等待集合。驗證超限行為時，只額外提交一筆，並排除同時有事件完成 Request 的競爭情況。

3. 結果與後續驗證

合法上限內且沒有事件時，Request 正常等待。若同時有一筆完成，後來提交的新 Request 可能仍在合法上限內，不能只看總提交次數判斷。

將 AERL+1 與每個時間點的未完成數比對，並保存回報事件造成的名額變化。

先確認 AERL 已加 1，且 Host 沒把已完成 Request 繼續算在等待集合中。

來源：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 §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)

回本冊題目

Q86 沒有掛入 AER 時發生事件，Controller 如何保留與回報？

跟著解說理解

這题区分事件發生與通知送達。沒有 Request，不表示事件一定沒發生；但也不能要求每種事件都永久排隊等待。

1. 機制與適用範圍

一般事件、Immediate 與 One-Shot 的規則不同；還要確認事件原本已啟用，且不是被遮蔽的重複通知。

一般 pending event 保存的是事件資訊，後續用 AER CQE 的 AET／AEI／LID 回覆。Immediate 必須在發生時已有 Request，否則不得回報。

2. 用操作與結果理解

檢查 OAES、FID0Bh、事件種類及 AER outstanding 紀錄。是否支援某個 Log，不足以證明所有相關事件都啟用。

建立無 Request 的受控期間，再觸發已啟用的一般事件，之後送 AER。期間若成功讀 Log 清除事件，或發生 CLR，就不能再要求後續一定收到原通知。

對一般已啟用事件，規範建議保留資訊供下一個 Request 回覆；這是 should，不是對所有種類的無條件永久保留要求。

3. 容易誤判的地方

沒有 Request 不會因此產生一筆超限或失敗 CQE。Immediate 未回報若符合上述條件，是規範要求，不能判為遺失事件的韌體缺陷。

比對事件時間、Request 時間、Log 確認及 CLR。只有把這些時間排清楚，才知道通知是否仍應存在。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.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)

回本冊題目

Q87 多個相同或不同事件同時發生時，Controller 如何合併與回報？

跟著解說理解

通知機制避免每次狀態變動都占用一筆 Request，但仍要讓 Host 找到需要處理的資訊。事件次數、Log entries 與 AER completions 不一定一對一。

1. 機制與適用範圍

相同 event type 且回覆內容相同的事件，可以合併；不同種類或不同回覆則有待回報的排隊建議。回報後的自動遮蔽也會影響後續通知。

以 AET、AEI、LID 及事件特定參數比較回覆，不要只比 AEI。相同 AEI 在不同類型中可能不是同一事件。

2. 用操作與結果理解

先確認每種事件受支援並啟用，並記錄可用 AER 數。只有一筆 Request 時，不能期待多個事件同時各回一筆 completion。

先觸發已知事件集合，逐筆接收並保存回覆，依規則讀 Log 與補 Request。確認後再觀察新的事件，避免把仍被遮蔽的通知當成未偵測。

相同回覆合併成一筆是 may；保留不同回覆的佇列是 should。規範沒有因此保證 AER 完成順序能還原所有內部事件的精確時間線。

3. 容易誤判的地方

合法合併不應被判為少回 completion 的錯誤。若 Host 同時送入過多 AER，則另依 1/05h 處理，與事件合併無關。

用 Log 的紀錄或 generation 補充通知，而不是把 AER 數量直接當成故障發生次數。

來源：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.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)

回本冊題目

Q88 Asynchronous Event Configuration 如何啟用或遮蔽特定事件？

跟著解說理解

FID0Bh 選擇 Host 希望接收的適用通知。這是通知政策，不會消除裝置已發生的健康問題，也不會自動提交 AER。

1. 操作前先準備什麼

設定以 controller 為操作對象，控制指定的 SMART 與選配事件通知。它不是所有 Error 類型事件的總開關。

讀 OAES 與相關能力，確認想啟用的事件受支援，再查 FID0Bh Current。設定支援和當下事件是否仍被遮蔽，是不同狀態。

Set Features.CDW11 的各 bit 選擇事件通知；Get Features 讀回 Current。這份 bitmap 不是 AER completion 的 AET／AEI 編碼。

2. 先後順序與完成條件

先設定合法的啟用值並等待成功，再讀回確認，確保有 AER 等待，最後建立事件條件。若條件在啟用前已成立，仍須依 Feature 的既有條件規則判斷。

成功表示設定已完成；Host 是否收到通知，還取決於事件條件、遮蔽與 Request。停用通知不代表該警告位一定清零。

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

啟用不支援的事件，必須回 Invalid Field（0/02h）。沒有 AER 而暫時收不到通知，不是 Set Features 的失敗 Status。

一起比對能力、Current mask、實際警告及 AER。只確認 Set 成功，不足以判斷通知路徑全部正常。

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

回本冊題目

Q89 SMART、Namespace、Firmware、Telemetry、Sanitize、Self-test 與 PEL 各有哪些通知條件？

跟著解說理解

這题要校正「每個功能完成都會有一種 AER」的假設。事件必須有規範定義，不能只因功能有 Log，就自行增加完成通知。

1. 事件何時成立、由誰觀察

事件可能描述 controller 健康、namespace 變更、韌體啟用或 sanitization target。不同 scope 的事件要讀不同資料，不只看接收它的 controller。

用 OAES、FID0Bh 與事件表確認選配通知。Device Self-test 支援位與 PEL 支援位，不會自動宣告一個通用的 Self-test Completed 或 PEL Changed AER。

SMART 類型使用 02h；namespace 變更依 Attached／Allocated 分別關聯 04h／1Ch；Firmware Activation Starting 關聯 03h；Telemetry Changed 關聯 08h；Sanitize 類型關聯 81h。

2. 通知、讀取與確認的關係

先辨認事件條件，再找對應 Log。Self-test 正常完成應查 06h 的結果；若另符合 Diagnostic Failure 的錯誤條件，才依該 Error 事件處理，不能將兩者等同。

Sanitize 有完成、非預期 deallocation 與進入 Media Verification 等不同事件，不可全部翻成清除成功。Firmware Activation Starting 也只表示開始，不是最終啟用成功。

3. 沒有通知或紀錄時怎麼判斷

某個操作沒有規定完成 AER 時，沒收到通知不是 Status 錯誤。判定漏報前，必須指出具體事件定義、支援、啟用及 Request 條件。

將實際操作結果、專用 Log 與 AER 條件分開核對，再以 PEL 的獨立支援事件補充歷史，不要求三者一對一。

先檢查期待的事件是否真的在本版規格中有定義，而不是由功能名稱推測。

4. Asynchronous Event 的通知條件

AER 的正常用途就是讓 controller 以完成這筆 Request 的方式回報事件。 完整條件見本冊說明

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.7 · 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 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2

本題原文定位

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.7 · 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 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2

回本冊題目

Q90 Host 讀取 Log 後，事件如何清除或保留？

跟著解說理解

事件確認控制後續通知是否重新開放，不是刪除全部歷史或修復根本原因。清除通知後，原警告可能仍存在。

1. 操作前先準備什麼

以該事件指定的 Log 與目標為準；讀取另一張 Log，或另一個 namespace 的資料，不一定確認目前這個事件。

先看事件是否採一般讀 Log 確認，還是 Immediate／One-Shot 的特殊方式。只有適用的事件才用 RAE 判讀。

RAE=0 表示成功完成後清除對應事件；RAE=1 表示保留。LID、NSID 與其他選擇欄位仍要符合事件對應的 Log 規則。

NSID
Namespace Identifier，邏輯儲存空間識別碼

2. 先後順序與完成條件

保存通知與原狀態，按需以 RAE=1 讀取，再以適用的 RAE=0 成功讀取確認。不要把任意片段讀取都當成每種 Log 通用的確認方法。

成功確認後，事件遮蔽依其規則解除；若狀態持續，後續通知仍可能再次出現。RAE 保留的是事件，不是保證回傳資料從此凍結。

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

Get 失敗時，事件必須保留。不能因 Host 寫了 RAE=0，就在 CQE 顯示失敗時仍要求事件消失。

比對成功 CQE 的時間、RAE、事件 mask 與後續通知。讀取時與事件發生時的即時值可能不同，不代表確認動作錯誤。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.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)

回本冊題目

Q91 AER 能否被 Abort？Reset 時尚未完成的 Request 如何處理？

跟著解說理解

AER 雖然沒有一般 timeout，仍是有 CID 的 Admin 命令。Host 停止使用事件通道時，要分清楚針對單筆 Request 的 Abort，與重設整個 controller 的處理。

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

Abort 以 SQID=0 與目標 AER 的 CID 指定它；Controller Reset 則影響此 controller 的全部 outstanding AER。

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

Abort 的並行上限由 ACL+1 決定，與 AERL+1 不同。沒有特殊的 AER Abort 成功保證，仍要依 Abort 結果判斷。

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

保留 Abort 自己的 CID、目標 CID，以及 CQE.DW0 的 IANP。IANP=0 表示已執行 immediate abort；IANP=1 不代表目標從此不會被 deferred abort。

送出 Abort 後，分別處理 Abort 與目標 Request 的結果。如果改採 Reset，則依重設規則終止舊追蹤，恢復後建立新的 AER，不能等待重設中止的舊 Request 回 CQE。

Abort 可能和事件完成競爭：目標可能先正常回報事件。真正被 Abort 的目標回 Command Abort Requested；被 Controller Reset 中止的 AER 則不得回 CQE，兩種情況不同。

3. 重設或斷電時，要確認什麼

觸發方式這項操作或狀態會如何變化
Controller Reset 後是否保留或繼續？Controller Reset 會中止尚未完成的 AER，而且這些被重設中止的 Request 不得回傳 CQE。Controller Level Reset 也會清除尚未通知的 pending event；Host 恢復後重新提交 AER，並依各 Log 的保留規則查詢狀態。

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

Abort 超限可回 Abort Command Limit Exceeded（1/03h）。目標已完成或未找到時，不能一律要求 Abort 本身失敗；應讀 IANP，並確認是否已有目標 completion。

核對同一 Admin Queue 使用期間內的 CID，避免 Reset 後重用 CID 時，把新 Request 當成舊 Abort 的目標。

先辨認 Request 是由 Abort 結束、事件完成，還是被 Reset 中止，再決定應不應有 CQE。

來源：Base 2.4 §5.2.2 (PCIe-applicable 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)

本題原文定位

來源：Base 2.4 §5.2.2 (PCIe-applicable 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)

回本冊題目

Q92 AER 已完成，但對應 Log 看不到預期資訊時，應如何定位？

跟著解說理解

通知描述曾發生的條件，Log 則可能描述目前狀態或有限歷史，因此兩者不一定是同一時點的副本。先找出資料類型，才能判斷是真的不一致。

1. 先保留哪些證據

固定 controller、事件 target 與讀取介面。共用資源的狀態可能已由另一個 Host 讀取或確認，不能只看本地程式紀錄。

核對 AET／AEI 的規範定義與 LID，再查支援能力及 Log 的更新、清除與保留規則。不要先假設每個事件都新增一筆 entry。

保留原 CQE、RAE、LID、NSID、LSI、讀取時間與有效欄位。SMART Critical Warning 反映處理 Get 時的狀態，可能已不同於事件發生時。

2. 依什麼順序排除原因

先檢查 Log 是即時狀態還是事件歷史，這決定它是否必須保留事件當時的數值。

先排除讀錯 Log 或對象，再檢查其他讀取、重設、generation 變化及 transient condition 已恢復。最後才比對規範是否要求仍能查到特定資訊。

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

例如溫度曾達門檻而觸發事件，稍後讀 SMART 時溫度已降低，兩者可以同時正確。相反地，More=1 的命令錯誤應有可關聯的補充資訊，須用相應規則檢查。

沒有預期資料不會自動改變已成功的 AER Status。若後續 Get 失敗，保留那筆命令的獨立錯誤，不能把兩筆結果混成一個。

完整結論要指出事件條件、Log 的資料時點及所有中間動作。只有在保留前提都成立時仍缺少必要資訊，才形成可驗證的矛盾。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

回本冊題目

共用規則：各題連到的完整解釋

這些規則在本冊只完整說明一次。返回剛才的題目可用瀏覽器「上一頁」；特定命令或 Feature 的明文例外優先。

本主題的共用條件 · 是否產生 Asynchronous Event？

AER 的正常用途就是讓 controller 以完成這筆 Request 的方式回報事件。必須分清楚事件本身、通知是否啟用、是否被遮蔽，以及是否還有 Request 可用；送出 AER 不會替 Host 啟用所有選配事件。

原文定位與既有圖表判讀

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.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–5.2.13.1.1
    文件頁 212–218 · PDF 238–244 · Figure 203–211
  • 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.14.2.1
    文件頁 340–387 · PDF 366–413 · Figure 338–341
  • Base 2.4 · §5.2.30.1.6
    文件頁 466–468 · PDF 492–494 · Figure 474

需要看欄位圖時

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

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