NVMe · Q1–328

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

Q205–Q216

Persistent Event Log 與 Timestamp

PEL 保存重要事件，Timestamp 協助解釋事件時間。本冊先教一致地取回完整 Log，再說明可變長度、事件類型與時鐘變更。

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

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

讀取的 context 與事件的持久性分開

事件仍保留，不代表舊 context 在 reset 後仍可沿用。

讀取步驟	需要欄位	注意事項
建立觀察範圍	ACT、RCE	ACT3 的 RCE=0 可表示剛建立成功
走訪 Log	LHL、TLL、TNEV	不能把每筆事件固定為同樣大小
解析事件	EHL、EL、VSIL	整筆=EHL+3+EL
解釋時間	Origin、SYNC、Timestamp Change	不能一律要求 timestamp 單調增加

舉例看懂：EHL=21、EL=20、VSIL=4 時，整筆事件 44bytes，其中 Event Data 為 16bytes。VSIL 已包含在 EL，若再加一次就會走錯下一筆。

來源：Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · NVM Command Set 1.3 §4.1.4.4 · Base 2.4 §5.2.30.1.8

需要時回顧本篇名詞

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 保留規則。

本冊題目

Q205 · 如何確認 Persistent Event Log 及個別事件的支援能力？
Q206 · PEL Context 如何建立、分段讀取與釋放？
Q207 · Context 不存在或重複建立時，應如何回應？
Q208 · SMART、Firmware、Timestamp、Reset 與 Hardware Error 如何記錄？
Q209 · Namespace、Format 與 Sanitize 對應哪些 Persistent Events？
Q210 · PEL 達容量上限時，舊事件如何處理？
Q211 · PEL 新增事件後，是否一定發送 Asynchronous Event？
Q212 · Reset 與 Power Cycle 後，PEL 哪些東西應保留？
Q213 · PEL 的 Header、長度與事件順序如何驗證？
Q214 · Timestamp 如何設定並以 Get Features 驗證？
Q215 · Timestamp 如何增加、Wrap-around，Origin 與 SYNC 怎麼看？
Q216 · Timestamp 變更如何記錄，Reset 與 Power Cycle 後怎麼判讀？

Q205 如何確認 Persistent Event Log 及個別事件的支援能力？

跟著解說理解

先確認整份 Log，再確認事件種類，才能判斷缺少紀錄是否合理。支援 PEL 不表示所有選配事件都必須實作。

1. 要查哪個對象、哪份資料

PEL 是 NVM subsystem 全域資訊；Header 中的 controller 識別不會把它變成私有 Log。

查 Identify.LPA 的 PEL 支援位元、PELS 的最大容量，以及 Supported Log Pages 對 LID0Dh 的宣告。建立 context 後再看 Supported Events Bitmap。

PELS 以 64 KiB 為單位；ECRH 表示 ACT=3 與 GNUM 支援。符合 Base 2.0 以後版本且支援 PEL 的實作必須設 ECRH=1。

2. 查詢順序與回覆判讀

確認 Log 能力後讀 Header，依事件支援及命令支援核對必要事件，再設計測試。

取得支援矩陣，而不是只得到「有／沒有 PEL」一個結論。

3. 證據不足或不一致時怎麼判斷

不支援的 LID 使用 Invalid Log Page 等對應錯誤；不能因某個選配事件未宣告就判定整份 Log 違規。

LID: Log Page Identifier，紀錄頁識別碼

Figure 233 的 bitmap 將 bits221:16 列保留，但 Figure 236 又列 ET10h，這是來源內部不一致；涉及該事件時須保留差異，不自行編造一致的位元表。

先檢查測試期待的事件是 mandatory、依命令支援而 mandatory，還是 optional。

來源：Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q206 PEL Context 如何建立、分段讀取與釋放？

跟著解說理解

Context 固定一份可一致讀取的事件集合，避免大型 Log 在分段傳輸期間被新事件改變內容。

1. 操作前先準備什麼

Context 是這次回報的視圖，不是停止 controller 記錄新事件。

確認 LID0Dh、ECRH 與 Header 的 TLL、LHL、GNUM、RCI。

ACT=1 建立並讀取；ACT=0 讀既有 context；ACT=2 釋放；ACT=3 建立或沿用 context 並固定回 512-byte Header。

2. 先後順序與完成條件

同一個 Context 的完整讀取流程

先固定回報視圖，再分段讀取；期間新增的事件留待下一次 Context 回報。

ACT=3 → 讀 Header
buffer 至少 512 bytes；記錄 GNUM、TLL 與回報 Context。
ACT=0 → 按 LPO 分段讀取
依 TLL 安排範圍，讓所有片段都來自同一個 Context。
讀完再核對 GNUM
相同：可確認這項一致性條件。不同：已讀資料可能無效，應重新讀取，不能只補最後一段。
ACT=2 → 釋放 Context
完成一致的讀取後釋放，再為下一次查詢取得新的回報視圖。

每段都保存 ACT、LPO 與 GNUM。Get Log Page 各自成功，不表示不同 Context 的片段可以混在一起。

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

ACT=0 無 context 或 ACT=1 已有 context，須回 Command Sequence Error。ACT=2 沒有 context 也不是錯誤。

來源：Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q207 Context 不存在或重複建立時，應如何回應？

跟著解說理解

這套介面不是讓 Host 建立多個不同 ID 的 Context。判斷命令順序是否正確，要看 ACT 要求的動作，以及目前是否已有 reporting context。

1. 先區分是哪一種失敗

判斷的是處理命令當下，是否已有 persistent reporting context。

RCE=0 代表這次命令處理前沒有 context；ACT=3 仍會建立成功，不能把 0 翻成建立失敗。

ACT=1 重複建立與 ACT=0 無 context 都是 Command Sequence Error，不能替這兩種條件改用假想的資源數量錯誤。

2. 用哪些資料確認原因

使用 ACT=3 的 RCE 與 RCPIT／RCPID，了解既有 context 及建立來源。

需要沿用就 ACT=0；要取得新事件集合，先協調讀者，再 ACT=2 釋放並重新建立。

3. 結果與後續驗證

ACT=3 不論原本是否存在都成功回 Header，RCE 區分先前狀態；ACT=2 可重複釋放。

把 CQE 成功與 RCE 的前置狀態放在一起解讀，兩者並不矛盾。

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

先檢查是否把 RCE 誤解成命令執行後的「目前已建立」布林值。

來源：Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q208 SMART、Firmware、Timestamp、Reset 與 Hardware Error 如何記錄？

跟著解說理解

每類事件有不同觸發點與資料格式；辨認事件後才能決定哪個欄位能回答問題。

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

Header.CNTLID 標示記錄來源；多 controller 的共同事件建議只記一次，事件資料可列多個 controller。

確認 PEL 與所需事件支援；PCIe 的 SMART Snapshot 是 PEL 支援後的必要事件。

ET01h 帶 512-byte SMART 快照；02h 帶 Firmware Commit 的 action、slot、status 與 requested revision；03h 帶變更前時間；04h 帶 reset descriptors；05h 以硬體錯誤代碼選 payload。

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

先讀 ET、ETR、EL，再按該格式解析。SMART 快照至少每 24 power-on hours 記錄一次；Reset 事件於重設完成時記錄。

Firmware NFR 代表要求啟用的版本，不保證已啟用；Reset descriptor 的 FA 能補充有無啟用及是否失敗。

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

硬體錯誤只要求記錄已支援且符合條件者，並有高頻抑制例外；不能要求每個命令 Invalid Field 都有硬體錯誤事件。

使用實際 CQE、Identify.FR、SMART 快照與事件 payload 互證，避免只憑事件名稱猜結果。

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

先確認使用的 ETR 與 payload 格式一致，並分清「要求」與「完成」。

4. Persistent Event 的記錄條件

PEL 的查詢不是另一筆 PEL 讀取事件。完整條件見本冊說明

來源：Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q209 Namespace、Format 與 Sanitize 對應哪些 Persistent Events？

跟著解說理解

管理操作的開始與完成可能相隔很久，需要不同事件才能重建過程。

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

Namespace 事件辨認目標 NSID；Format 與 Sanitize 還要依命令判斷單一 namespace 或較廣範圍。

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

確認操作支援與事件支援；PEL 的條件性必要事件隨對應命令能力判斷。

ET06h 記 Namespace Create／Delete；07h、08h 為 Format Start／Completion；09h、0Ah 為 Sanitize Start／Completion。NVM 的 FLBAS、DPS 解釋來自 NVM Command Set。

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

以目標、action、開始資料與完成資料配對；Attach／Detach 不是 Namespace Create／Delete，不應硬套 ET06h。

Format completion 需連 FNVMS 與 INFO 判讀；Sanitize 進入 Media Verification 並不等於已產生正常最終完成事件。

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

Reset 導致沒有 Format CQE 時，不能把紀錄中保留或零值 Status 當成成功證明。

NVM Namespace 刪除全部時，FLBAS／DPS 保留；單一刪除則描述被刪前的格式，不能在物件消失後仍要求 Identify 可讀。

先檢查這筆紀錄是 Start 還是 Completion，以及完成資料是否真的有效。

4. Persistent Event 的記錄條件

PEL 的查詢不是另一筆 PEL 讀取事件。完整條件見本冊說明

來源：Base 2.4 §5.2.13.1.14.2.6 · Base 2.4 §5.2.13.1.14.2.7–5.2.13.1.14.2.8 · Base 2.4 §5.2.13.1.14.2.9–5.2.13.1.14.2.10 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q210 PEL 達容量上限時，舊事件如何處理？

跟著解說理解

PEL 有容量限制，Host 不能假設所有事件從出廠開始永久逐筆保存。

1. 機制與適用範圍

限制可能來自總 bytes、總事件數，或個別事件類別的內部容量。

到達限制後，刪除哪些事件由廠商決定，可能保留較舊但較重要的紀錄；不保證嚴格 FIFO。

2. 用操作與結果理解

查 PELS、TLL、TNEV 與產品的廠商定義政策；Header 的目前數量不是終身發生次數。

取得前後兩份完整 context，按事件內容比對，再考慮容量淘汰、高頻抑制與 Sanitize 的影響。

Controller 可回報仍保留的有效集合；事件數沒有單調增加，不足以單獨判定資料遺失違規。

3. 容易誤判的地方

規範建議容量足以支應使用壽命，但這是 should；不能改寫成永遠不得淘汰的 shall。

GNUM 表示新 context 的內容相較前次改變，不是累計事件總數；兩者不應混算。

本題原文定位

回本冊題目

Q211 PEL 新增事件後，是否一定發送 Asynchronous Event？

跟著解說理解

PEL 新增紀錄，不代表一定會發出 AER。持久事件紀錄與非同步通知有各自的觸發條件，要分開判斷。

1. 紀錄與通知各自有哪些條件

PEL 提供跨重設歷史；AER 回報受支援且符合通知條件的即時事件。

分別查 Supported Events Bitmap 與 AER/AEC 的支援設定，不能拿 PEL bitmap 當 AER 遮罩。

例如 SMART Critical Warning 可能同時符合 PEL hardware event 與 SMART AER；一般 Timestamp Change 則沒有因此定義一個 PEL Changed 通知。

2. 如何建立正確的驗證預期

先找造成 PEL 紀錄的原始事件，再檢查它是否另有 AER 類型、設定、遮蔽與 request 條件。

可能只看到 PEL，也可能兩者都有；須按事件種類而不是按「Log 改了」判定。

為每個測試列出兩條獨立預期：是否記錄，以及是否通知。

來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.30.1.6 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q212 Reset 與 Power Cycle 後，PEL 哪些東西應保留？

跟著解說理解

要分清持久事件與暫時的讀取 context：事件保留不表示查詢可以從中斷處無條件接續。

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

持久性涵蓋 subsystem 的事件內容；context 則服務一次一致的報告讀取。

保存重設前的完整 Header、事件資料與 GNUM，重設後重新建立 context。

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

新 Header 的時間、GNUM、事件數可能改變；新增 Power-on or Reset entry 也會改變低 offset 的事件排列。

按事件內容與來源關聯前後紀錄，不要求同一事件永遠位於同一 byte offset。

原有持久事件依保留規則仍可讀；context 若已失效，就重新開始一致的讀取。

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

觸發方式	這項操作或狀態會如何變化
Controller Reset 後是否保留或繼續？	Controller Level Reset 後，PEL 事件內容須保留，但查詢 context 不保證仍有效。恢復查詢通道後重新建立 context，不能把中斷前的半份資料接上新的 context。
NVM Subsystem Reset 後是否保留或繼續？	Subsystem Reset 不清除持久事件；Reset 完成時還可能依支援規則新增 Power-on or Reset 事件。報告 context 的保留是另一回事，應重新建立一致的讀取範圍。
Power Cycle 後是否保留或繼續？	事件內容須跨 Power Cycle 保留，規範也建議設計盡量降低失電時的事件遺失。容量淘汰、高頻抑制，以及 Sanitize 為避免洩漏使用者資料而移除或修改事件，是不同的例外，不能把它們誤認為一般斷電清空。

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

不能把舊 context 的 Command Sequence Error 當成 PEL 已清空。容量淘汰、抑制或 Sanitize 也需獨立排除。

用新 context 取得的完整資料驗證事件，而不是只檢查 Reset 前後第一筆是否相同。

先確認消失的是事件本身，還是只失去讀取 context。

本題原文定位

回本冊題目

Q213 PEL 的 Header、長度與事件順序如何驗證？

跟著解說理解

PEL 是可變長度紀錄，錯算一個長度會讓後面每筆事件都解析錯位。

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

先區分「整份 Log」與「單筆事件」兩層資料。Log Revision（LREV）指出整份 Log 的格式版本；每筆事件內的 Event Type Revision（ETR）則指出該類事件資料的格式版本。兩者不是同一個版本欄位，解析時要分別確認。

先由 Identify Controller.LPA 確認 PEL 支援能力，再讀 Log Header。Total Log Length（TLL）是整份資料的 bytes 數，Total Number of Events（TNEV）是事件筆數；Log Header Length（LHL）用來計算第一筆事件從哪裡開始，Generation Number（GNUM）則用來辨認 Log 是否已更新。界定整份資料後，再檢查每筆事件的長度。

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

LHL 的計算起點是 Log 的 byte 20，因此 Log Header 總長為 LHL+20。每筆事件的 Event Header Length（EHL）也不包含最前面的 3 bytes，所以事件標頭總長為 EHL+3。Event Length（EL）描述標頭後方的資料，且已包含 Vendor Specific Information Length（VSIL）指定的廠商資訊；因此整筆事件長度是 EHL+3+EL，而扣除廠商資訊後的 Event Data 長度是 EL−VSIL。

從 Header 結尾開始，依每筆總長前進並檢查界限。例如 EHL=21、EL=20、VSIL=4，整筆 44 bytes，其中 Event Data 為 16 bytes。

解析完 TNEV 筆事件後，所有已解析的事件都應落在 TLL 指定的有效資料範圍內。每筆事件不保證從 4-byte 對齊的位置開始，因此不能擅自插入 padding，否則下一筆事件的起點就會算錯。

3. 判讀時要保留的條件

若 VSIL>EL，表示宣告的廠商資訊比包含它的資料範圍還大；若事件結尾超過 TLL，則表示解析結果已超出整份 Log。這兩種情況都需要檢查長度欄位與取得的資料是否一致。Get Log Page 的傳輸對齊要求，不會讓每筆事件自動變成相同長度。

較新事件建議放較低 offset，但發生順序判定由廠商決定；Timestamp 可改變，不能直接依數值重排後宣稱原 Log 錯誤。

本題原文定位

回本冊題目

Q214 Timestamp 如何設定並以 Get Features 驗證？

跟著解說理解

Timestamp 讓 Host 提供事件關聯用的時間基準；它不保證可作安全用途，也不是所有 controller 共用的一只時鐘。

1. 操作前先準備什麼

設定作用於目標 controller；跨 controller 比對仍需處理時間差與 Reset 資訊。

查 Identify.ONCS 的 Timestamp 支援，以及 FID0Eh 的保存能力。

Set 傳 8-byte buffer，bytes5:0 為自 1970-01-01 UTC 起的毫秒數，bytes7:6 保留；Get 多回 Timestamp Origin 與 SYNC。

2. 先後順序與完成條件

先記錄 Host 時間，送 Set 並等成功，再 Get Current；比較時容許已經過的時間，而不是要求與 Set 值逐 byte 相等。

Origin=001b 表示由 Set Features 初始化；回值為設定值加上 controller 計入的經過時間。

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

不支援的 Feature、非法欄位或 Save 要求依各自 Feature 錯誤回應。不能把失敗 Set 當成時鐘已更新。

比較設定、Origin、SYNC 與讀取時間點，再決定差值是否合理。

來源：Base 2.4 §4.4 · Base 2.4 §5.2.12 · Base 2.4 §5.2.30.1 (common fields, scope and persistence) · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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)

本題原文定位

回本冊題目

Q215 Timestamp 如何增加、Wrap-around，Origin 與 SYNC 怎麼看？

跟著解說理解

同樣的數字可能是 UTC 時間，也可能只是 Reset 後經過時間；必須先解讀屬性。

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

48-bit 值屬於該 controller 的時間基準，不能直接推論跨 controller 的絕對先後。

Get FID0Eh Current，讀 Timestamp 及 TSTMPS；需要歷史變更時搭配 PEL 的 Timestamp Change。

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

Origin=000b 表示 CLR 初始化為 0；001b 表示 Host Set 初始化。SYNC=0 表示初始化後連續計毫秒；SYNC=1 表示可能省略廠商定義的時間區間。

先確認 Origin，再算經過時間；設定值加經過時間超出 48 bits 時，回報值應以 2^48 取模。

在相同基準且沒有其他變更時，差值可按 48-bit 模數計算；SYNC=1 則不能要求與壁鐘完全一致。

3. 判讀時要保留的條件

時間變小可能是 Wrap-around、重設、恢復 Saved 或重新 Set，不必然代表計數器壞掉。

用 Origin、SYNC、Reset 事件與 Timestamp Change 排除基準切換後，再比較先後。

本題原文定位

回本冊題目

Q216 Timestamp 變更如何記錄，Reset 與 Power Cycle 後怎麼判讀？

跟著解說理解

事件時間會因校時而不連續，Timestamp Change 提供連接新舊時間基準的資訊。

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

變更與 Reset 都要依相關 controller 判讀，不能把整個 subsystem 當成單一時鐘。

確認 Timestamp 與 PEL 支援，保存目前值、Origin、SYNC、Saved 及 Reset 來源。

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

ET03h 的 Header 時間描述新時間，PTSTP 保存變更前時間，MSR 表示距上次 CLR 的毫秒數。

先用 PTSTP 與 Header 建立新舊基準關係，再用 MSR、Power-on or Reset descriptors 比對控制器間的觀察。

若 CLR 持續維持 Timestamp，Origin 也必須保留；若不維持，須按初始化與可能的 Saved 恢復重新解讀。

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

觸發方式	這項操作或狀態會如何變化
Controller Reset 後是否保留或繼續？	若此種 CLR 保持 Timestamp 持續計時，就必須保留 Origin；不保持時則依 Timestamp 的初始化／保存規則重新判讀。
NVM Subsystem Reset 後是否保留或繼續？	對每個受重設 controller 分別檢查 Timestamp 是否持續及 Origin；不能假設 subsystem 中所有時鐘數值完全相同。
Power Cycle 後是否保留或繼續？	若功能可保存且曾保存，恢復的是 Saved 值，時間可能向後跳；不能要求斷電期間仍一定連續增加。

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

不能把校時造成的時間倒退判成 PEL 順序違規，也不能把 Timestamp 記成 ET0Bh 的普通 Set Feature 事件。

重設後的 Get、Timestamp Change 與 Power-on or Reset 應能形成合理的時間解釋，但不能假設所有事件時間都單調增加。

先檢查時間是否被重新設定或恢復 Saved，再調查事件排序。

5. 分開核對事件通知與 Log 紀錄

Set Timestamp 本身沒有一般的成功 AER；事件時間可能因此改變，但不代表須送出 PEL Changed 通知。完整條件見本冊說明

Timestamp 使用專屬 Timestamp Change Event，不得記成一般 Set Feature Event。完整條件見本冊說明

來源：Base 2.4 §4.4 · Base 2.4 §5.2.13.1.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding) · Base 2.4 §5.2.30.1.8 · NVM Command Set 1.3 §4.1.4.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.30.1 (common fields, scope and persistence)

本題原文定位

回本冊題目

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

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

本主題的共用條件 · 是否記錄於 Persistent Event Log？

PEL 的查詢不是另一筆 PEL 讀取事件。只有受支援的原始事件才依各自觸發條件記錄；高頻相同事件可依規範允許的廠商門檻抑制，不能要求無限逐筆重複。

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

Set Timestamp 本身沒有一般的成功 AER；事件時間可能因此改變，但不代表須送出 PEL Changed 通知。

本主題的共用條件 · 是否記錄於 Persistent Event Log？

Timestamp 使用專屬 Timestamp Change Event，不得記成一般 Set Feature Event。

原文定位與既有圖表判讀

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 · §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.2 (PCIe-applicable events)
文件頁 183–191 · PDF 209–217 · Figure 150–160
Base 2.4 · §5.2.12
文件頁 209–212 · PDF 235–238 · Figure 197–202
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.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.14–5.2.13.1.14.2.5 (exclude PCIe link/packet decoding)
文件頁 244–256, 258 · PDF 270–282, 284 · Figure 232–244, 246
Base 2.4 · §5.2.13.1.14.2.2, 5.2.13.1.14.2.4
文件頁 252–255 · PDF 278–281 · Figure 238, 240–241
Base 2.4 · §5.2.13.1.14.2.6
文件頁 258–259 · PDF 284–285 · Figure 247
Base 2.4 · §5.2.13.1.14.2.7–5.2.13.1.14.2.8
文件頁 259–261 · PDF 285–287 · Figure 248–249
Base 2.4 · §5.2.13.1.14.2.9–5.2.13.1.14.2.10
文件頁 261–262 · PDF 287–288 · Figure 250–251
Base 2.4 · §5.2.14.2.1
文件頁 340–387 · PDF 366–413 · Figure 338–341
Base 2.4 · §5.2.30.1 (common fields, scope and persistence)
文件頁 456–460 · PDF 482–486 · Figure 463–466
Base 2.4 · §5.2.30.1.6
文件頁 466–468 · PDF 492–494 · Figure 474
Base 2.4 · §5.2.30.1.8
文件頁 469–471 · PDF 495–497 · Figure 479–480
NVM Command Set 1.3 · §4.1.4.4
文件頁 76–77 · PDF 76–77 · Figure 112

需要看欄位圖時

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

使用的原始文件

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

NVMe 自問自答題庫：Persistent Event Log 與 Timestamp

讀取的 context 與事件的持久性分開

本冊題目

Q205 如何確認 Persistent Event Log 及個別事件的支援能力？

1. 要查哪個對象、哪份資料

2. 查詢順序與回覆判讀

3. 證據不足或不一致時怎麼判斷

Q206 PEL Context 如何建立、分段讀取與釋放？

1. 操作前先準備什麼

2. 先後順序與完成條件

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

Q207 Context 不存在或重複建立時，應如何回應？

1. 先區分是哪一種失敗

2. 用哪些資料確認原因

3. 結果與後續驗證

Q208 SMART、Firmware、Timestamp、Reset 與 Hardware Error 如何記錄？

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

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

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

4. Persistent Event 的記錄條件

Q209 Namespace、Format 與 Sanitize 對應哪些 Persistent Events？

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

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

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

4. Persistent Event 的記錄條件

Q210 PEL 達容量上限時，舊事件如何處理？

1. 機制與適用範圍

2. 用操作與結果理解

3. 容易誤判的地方

Q211 PEL 新增事件後，是否一定發送 Asynchronous Event？

1. 紀錄與通知各自有哪些條件

2. 如何建立正確的驗證預期

Q212 Reset 與 Power Cycle 後，PEL 哪些東西應保留？

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

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

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

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

Q213 PEL 的 Header、長度與事件順序如何驗證？

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

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

3. 判讀時要保留的條件

Q214 Timestamp 如何設定並以 Get Features 驗證？

1. 操作前先準備什麼

2. 先後順序與完成條件

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

Q215 Timestamp 如何增加、Wrap-around，Origin 與 SYNC 怎麼看？

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

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

3. 判讀時要保留的條件

Q216 Timestamp 變更如何記錄，Reset 與 Power Cycle 後怎麼判讀？

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

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

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

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

5. 分開核對事件通知與 Log 紀錄

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

本主題的共用條件 · 是否記錄於 Persistent Event Log？

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

本主題的共用條件 · 是否記錄於 Persistent Event Log？

原文定位與既有圖表判讀

需要看欄位圖時

Jia-Chang

Recent posts

Comments