NVMe · 規格與原理

NVMe Persistent Event Log：讀取流程、事件格式與歷史判讀

00.01.裝置重設後，如何知道之前發生過什麼？Persistent Event Log 保存跨重設的重要事件，將健康快照、韌體更新、電源、namespace 與設定變更放進共同的紀錄格式。本篇先說明如何讀出同一份資料，再學會把時間、對象、參數與結果連起來，同時分辨紀錄能證明什麼、不能證明什麼。

Persistent Event Log: 持久事件紀錄；保存subsystem重要事件的LID 0Dh紀錄。
namespace: namespace，主機透過 controller 存取的一份已格式化非揮發性容量。

這篇的主軸

這份歷史保存什麼

01-01事件種類支援、保存上限與實際內容是三件事。先認識 subsystem 範圍、持久性與遺漏的可能性，避免把有限紀錄當作完整流水帳。

一次讀取的生命週期

02-01建立 context → 讀 header → 分段讀取 → 比對 generation → 釋放。新事件與正在讀的事件集合分開，才能理解為什麼需要context。

context: 本次讀取使用的回報內容與追蹤資訊；建立後新增的事件不加入其中。
header: 資料前端的共同說明區，記載種類、大小、版本等讀取內容所需資訊。

資料的三層結構

03-01外層log header描述整份報告；共同event header描述一筆事件；ED保存該種類的內容。每一層長度和版本各有用途。

ED: Event Data，扣除共同header與廠商附加資訊後的事件內容。

從事件還原合理的關係

04-01按健康、時間／重設、儲存變更、清除、硬體及設定分組。一起看對象、動作和結果，不以單一名稱、百分比或時間戳推論成功。

Base 與 NVM 怎麼接起來

05-01Base提供Namespace Change外框，NVM補定FLBAS與DPS。最後再學廠商擴充，遇到未知內容也能辨認範圍並保留原始資料。

FLBAS: Formatted LBA Size，保存格式編號與metadata傳輸方式，不是直接記錄bytes大小。
DPS: End-to-end Data Protection Type Settings，資料保護資訊的類型及位置設定。
NVM: Non-Volatile Memory，斷電後仍能保存資料的記憶體。

00.02.適合已學過OS、Computer Organization並了解SSD基本概念的讀者。文中的控制器A／B、namespace7及示範數值只用來說明規則，不代表每台裝置都有相同配置。

00.03.中文教學版以循序推理與欄位案例深入學習；中英文post先建立全局觀念，再接續順向Spec報告路徑。主範圍固定為上述兩節，其他來源只補足理解事件所需的欄位。

把主軸連起來

00.04.可以把整篇想成五個連續問題：這台裝置會記什麼；這次讀到哪一份；每筆從哪裡開始；事件內容代表什麼；最後能做出什麼有根據的判斷。前一個問題沒弄清楚，後面的數字就容易讀錯。

00.05.本文用流程圖說明context，用資料區塊圖說明長度，用時間與對象的對比解釋事件。規格欄位很多時採分組表格，共用格式只解釋一次，再由每張圖的獨立案例連回。

01 先分清事件歷史、目前狀態與完整性

01.01.Persistent Event Log（PEL，LID 0Dh）保存 NVM subsystem 的重要事件，跨 power cycle 與 reset 保留。它不是每筆 I/O 的流水帳，也不是永遠不會遺失的完整歷史：容量、同類事件數量、頻率抑制與淘汰策略由廠商決定，Sanitize 也可能移除或修改紀錄。

NVM subsystem: NVM subsystem，包含 controller、port、namespace 與非揮發性儲存資源的 NVMe 系統邊界。
power cycle: 斷電再上電的電源循環；不等同所有形式的reset。
I/O: Input/Output，對 namespace 執行資料輸入與輸出的操作類別。
LID: Log Page Identifier；指定要讀取哪一種 log page 的編號。
PEL: Persistent Event Log，本篇的持久事件紀錄。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 244-245, PDF 頁 270-271

01.02.先用 Identify Controller 的 LPA.PES 確認支援，PELS 以 64 KiB 為單位回報最大空間；本次實際回報長度則是 PEL header 的 TLL。SEB 宣告事件種類支援，TNEV 計算這次回報有多少筆，兩者不能互相代替。

PELS: Persistent Event Log Size，最大PEL空間，以64KiB為單位。
TNEV: Total Number of Events，本次回報實際包含的事件筆數。
LPA: Log Page Attributes，Identify Controller中回報log相關能力的欄位。
PES: Persistent Event Support，LPA內表示是否支援PEL的bit。
SEB: Supported Events Bitmap，按事件種類宣告支援的位元圖。
TLL: Total Log Length，這份回報包含header在內的總byte長度。

來源：Base 2.4 §5.2.14.2.1; 5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1; 5.2.13.1.14, 文件頁 247-249,355,364, PDF 頁 273-275,381,390

先想一個實際要回答的問題

01.03.裝置重設後恢復服務，你想知道之前是否更新過韌體、是否發生電源中斷、是否重新建立過 namespace。現在的設定只能告訴你「目前怎樣」，PEL 則留下事件當時的資訊。這種差異就像目前的銀行餘額與交易紀錄：兩者可以互相說明，卻不是同一份資料。這個比喻只幫助理解用途，不表示 PEL 具有帳本的完整性保證。

先看支援，再看這份紀錄實際有什麼

01.04.可以把讀取分成三個問題：裝置能不能提供 PEL；它支援記錄哪些事件；這次實際回傳哪些事件。PES、SEB、TNEV 分別回答它們。例如裝置支援 Thermal Excursion，這次卻沒有溫度事件，可能只是沒有觸發，不能推論裝置不支援。反過來，紀錄裡沒有某件事，也不能直接斷言它從未發生。

持久不代表無限，也不代表每次斷電都零遺失

01.05.規格要求跨重設與電源循環保留，但對突發斷電造成的事件遺失，使用的是「設計應盡量降低」的要求。容量或同類事件上限滿了，刪除哪些紀錄由廠商決定，不能自動假設一定刪最舊。事件太密集時也可以按廠商門檻抑制重複事件；因此計算 log 裡某類事件筆數，不等於可靠的終生發生次數。

如何安排閱讀順序

01.06.先學會取得同一份資料，再學外框與長度。接著依問題讀事件：健康與溫度、時間與重設、namespace 與格式、清除作業、硬體、設定及擴充。範圍內每張規格表都在後面的圖表教學區有重點、案例與欄位說明；需要細節時可以直接從本單元連過去，不必把所有欄位一次背完。

閱讀相關規格圖表 → 先分清事件歷史、目前狀態與完整性

02 用 reporting context 取得同一份紀錄

02.01.Reporting context 固定本次回報的事件集合；之後新增的事件仍須記錄，但不加入既有 context。ACT=1 建立並讀取，已有 context 時失敗；ACT=0 讀取既有 context，沒有時失敗；ACT=2 釋放，沒有也不是錯誤。受支援的 ACT=3 建立或沿用 context，一律回傳 offset 0 的 512-byte header。

offset: 相對指定起點的位移；本篇未另註明時以bytes計算，從0起算。
ACT: Action，Get Log Page中選擇PEL讀取、建立或釋放的動作。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-246,251, PDF 頁 271-272,277

02.02.ACT=3 回覆的 RCE 表示處理命令前是否已有 context；RCE=0 不表示建立失敗。分段讀取應先記下 GNUM，完成後重讀比較；不同表示資料可能來自不同 context，應重新取得。GNUM 只有建立新 context 且內容與上次不同才遞增，16-bit 值會回捲。

GNUM: Generation Number，用於比較分段讀取前後是否仍是同一代回報內容。
RCE: Reporting Context Exists，表示處理命令前是否已存在context。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-248, PDF 頁 271-274

02.03.Get Log Page 的 NUMD 是從 0 計數的 Dword 長度；512 bytes 對應 NUMD=127。PEL 是 subsystem 範圍，NSID 使用 0 或 FFFFFFFFh。一般以 OT=0 使用 byte offset；ACT=2 忽略長度與 offset，ACT=3 也忽略它們而固定回 512 bytes，因此 buffer 至少配置 512 bytes。

Dword: Dword（Double word）；32 bits，也就是 4 bytes。對比 word=16 bits；例如 zero-based dword count=3 代表 4 個 Dwords，也就是 16 bytes。
NSID: Namespace Identifier，controller 用來指向 namespace 的數值 handle；identifier 不等於 namespace 物件本身。
NUMD: Number of Dwords，0's-based transfer dword count；實際 bytes = (NUMD + 1) × 4。

來源：Base 2.4 §5.2.13; 5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13; 5.2.13.1.14, 文件頁 213-217,246, PDF 頁 239-243,272

為什麼不能讀一塊就重新建立一次

02.04.一份 PEL 可能比單次傳輸大。假設先讀到 A、B，裝置此時新增 C；如果下一次又從另一份事件集合取資料，接起來就可能漏掉或重複某筆。Context 用來固定這一次要報告的集合與資料位置。它不停止裝置記錄新事件，只讓讀取者能分批完成同一份報告。

選擇建立動作後，再用讀取動作接續

02.05.一般先確認沒有其他讀取者佔用或管理這份 context，再使用 ACT=1 建立，或使用支援的 ACT=3。後續分段用 ACT=0，加上各段的 offset 與長度。ACT=3 若回 RCE=1，是沿用既有 context，不能當成剛取得含最新事件的新快照；若要更新，應在讀取者之間協調後釋放，再建立。不要任意釋放別人正在使用的 context。

箭頭表示主機讀取順序。context仍可能因reset或保留期限失去；GNUM變化表示這次內容可能不一致，應重新取得。ACT3沿用舊context時不自動納入新事件。來源：Base §5.2.13.1.14、Figure232。

讀取期間仍可能失去 context

02.06.規格建議保留 context，直到主機釋放、subsystem reset、controller level reset，或廠商規定足夠完成讀取的一段時間。不能因 ACT=1 成功就假設永遠存在。先讀 header 記下 GNUM 與 TLL，收齊資料後再讀 header，比對 GNUM；若變了，這次拼接的結果不應當作一致資料。

controller: controller，實作 NVMe 介面、取走 command 並回報 completion 的控制實體。

讀完再釋放，而不是每一段釋放

02.07.ACT=2 只處理釋放，不回傳 log data，也不依 NUMD 或 offset 讀資料。主機完成一份報告後應釋放 context，讓下一次建立能包含新事件。釋放 context 與清除持久事件歷史是兩件事；前者結束這次讀取，不是一個刪除所有 PEL 事件的命令。

閱讀相關規格圖表 → 用 reporting context 取得同一份紀錄

03 從 header 走到每筆事件的邊界

03.01.LHL 的計數不含前 20 bytes，因此 log header 大小是 LHL+20；EHL 不含事件前 3 bytes，因此事件 header 大小是 EHL+3。EL 已包含 VSIL 指出的廠商資料，事件總大小為 EHL+3+EL，真正 ED 大小為 EL−VSIL。LREV 描述外層格式，ET 與 ETR 決定事件內容的格式。

LREV: Log Revision，整份log與共同event header的格式版本。
VSIL: Vendor Specific Information Length，可選廠商附加資料的byte長度。
EHL: Event Header Length，單筆event header中前3 bytes之後的長度。
ETR: Event Type Revision，該種類事件內容的格式版本。
LHL: Log Header Length，log header中前20 bytes之後的長度。
EL: Event Length，事件header之後VSI與ED合計的byte長度。
ET: Event Type，事件種類代碼。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 247-251, PDF 頁 273-277

先分清位置、長度和第幾筆

03.02.Offset 是離起點多少 bytes；index 是第幾筆。現在的 log header 佔 512 bytes，所以第一筆事件從 offset 512 開始，它的 index 是 0。第二筆從哪裡開始，必須把第一筆的實際總長度加上去。事件不是每筆固定 512 bytes，也不能用 index 乘固定常數當 offset。

index: 項目編號；要連同表格規則判斷從0或1起算，與byte位置不同。

先看外框，再看內容

03.03.每筆事件先有共同 header：ET 告訴你是什麼事件，ETR 告訴你用哪一版內容，CNTLID 與 ETSTP 說明記錄者與時間。接著可能有 VSI，最後才是 ED。沒有 VSI 時 VSIL=0；沒有 ED 時也可能仍有一個有效事件，例如進入 Media Verification 的 ET=0Eh。不要把「沒有內容」當成「沒有事件」。

ETSTP: Event Timestamp，共同header內記錄事件發生時間的欄位。
VSI: Vendor Specific Information，共同事件格式中可選的廠商附加資訊。

說明性算例：起點512、EHL21、VSIL4、EL20。圖示寬度為排版用，不按byte數比例。上排是結構，下排是相對log起點的實際位置。來源：Base Figure234。

用算例走一次，不背表格中的長算式

03.04.假設事件從 offset 512 開始，EHL=21、VSIL=4、EL=20。共同 header 為 24 bytes，VSI 在 536～539，ED 在 540～555，長 16 bytes；下一筆從 556 開始。EL 的 20 已是 4+16，再多加 VSIL 會錯跳到 560，把下一筆開頭跳掉。這就是原表把長度分開的理由。

先確認邊界，再按版本解讀

03.05.整份事件區不得超出 TLL，每筆的 VSIL 不應大於 EL，前進後的 offset 也不得超過回報邊界。事件本身長度未保證是 4 的倍數；傳輸請求的 Dword 對齊是另一層限制，可以讀取包含部分事件的資料塊後再組合。遇到尚未支援的 ET 或 ETR，先保留原始 bytes、依外框長度走到下一筆，不拿相似事件格式硬解。

閱讀相關規格圖表 → 從 header 走到每筆事件的邊界

04 健康、Telemetry 與溫度各留下什麼證據

04.01.ET=01h 保存 512-byte SMART 快照，記錄間隔不得超過 24 power-on hours；ET=0Ch 可保存新建 Telemetry 的前 512 bytes，並不包含完整診斷資料。ET=0Dh 記錄溫度門檻事件，其 OTMP 是相對門檻的 Kelvin 差值，不是絕對溫度。這些都是事件當時的資料。

Telemetry: 控制器或subsystem內部狀態的診斷資料；本篇事件只保存其header。

來源：Base 2.4 §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13, 文件頁 252,264-266, PDF 頁 278,290-292

04.02.SMART 的 Data Units Read／Written 使用 1000×512-byte 單位、向上取整；Composite Temperature 使用 Kelvin。Telemetry 的 Last Block 是由 block 1 開始之資料區的最後編號，各資料區是由同一起點擴大的集合，不是要相加的四段。

來源：Base 2.4 §5.2.13.1.3; 5.2.13.1.8; 5.2.13.1.9

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3; 5.2.13.1.8; 5.2.13.1.9, 文件頁 221-225,234-237, PDF 頁 247-251,260-263

快照先問拍攝時間

04.03.一份 PEL 裡的 SMART 是當時拍下的 512-byte 健康資料。今天讀到去年快照的 POH、Data Units 或警告，不能把它當成今天的數值。沒有虛擬化時各控制器都要按規定間隔記錄；有虛擬化時是各 primary controller。24 hours 指 power-on hours，裝置關機幾天不會因此把它變成每個日曆日一筆。

POH: Power On Hours，self-test result 建立時累積的 power-on hours，不含指定 low-power 時間。

單位決定比較是否有意義

04.04.SMART 累計量要連同單位閱讀：忙碌時間用分鐘、電源時間用小時、熱管理累積時間用秒，溫度用 Kelvin。Data Units=3 不是 3 bytes，也不是精確 3000 個 512-byte 單位，而是向上取整後的結果；原計數落在 2001～3000 個單位。零值有些表示未回報，不能把所有零都解成從未發生。

三種事件，回答三個問題

事件	保存什麼	可以回答什麼
01h SMART	512-byte健康快照	當時的健康與累計量
0Ch Telemetry	診斷資料的前512-byte header	當時捕捉了哪一份資料，邊界為何
0Dh Thermal	門檻代碼與相對溫差	跨過哪種門檻或改變哪種熱管理狀態

Telemetry事件未保存資料blocks；Thermal事件也不是另一份完整SMART。來源：Base Figures237、254、255。

Telemetry 事件是一張索引卡

04.05.ET=0Ch 留下 Telemetry header：可辨認廠商、原因、作用範圍、generation number 和各資料區邊界。若 header 說 Data Area 3 結束於 block 9，意思是原始診斷資料區曾涵蓋 blocks 1～9；這 9 個 blocks 並沒有跟著收入此 PEL 事件。歷史 header 也不保證現在裝置還留著同一份原始資料。

溫度差值要搭配觸發門檻

04.06.若 THRESH=1、已知 WCTEMP=343 K、OTMP=5，這是往上跨過警告門檻的事件，可理解為約 348 K 的當時溫度。THRESH=88h 是回到正常區間，89h 是停止某種熱管理動作，兩者又是不同事件。遇到廠商門檻或不知門檻值時，只靠 OTMP 不能還原絕對溫度；Kelvin 差 5 與 Celsius 差 5 相同，但絕對值需要減 273.15。

WCTEMP: Warning Composite Temperature Threshold，Identify Controller 回報的 composite warning threshold。

閱讀相關規格圖表 → 健康、Telemetry 與溫度各留下什麼證據

05 韌體、時間戳與重設要連著讀

05.01.Firmware Commit 完成時記錄 ET02，不代表新韌體已啟用；ET04 在 power-on 或 reset 完成後，提供成為有效版本的 FREV 與各控制器資訊。ET03 保存時間戳變更前的 PTSTP，而共同 header 的 ETSTP 是變更後的時間。時間戳可能由重設起算、由主機設定，也可能有停止計時區間。

來源：Base 2.4 §5.2.13.1.14.2.2; 5.2.13.1.14.2.3; 5.2.13.1.14.2.4; 5.2.30.1.8

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.2; 5.2.13.1.14.2.3; 5.2.13.1.14.2.4; 5.2.30.1.8, 文件頁 252-254,470-471, PDF 頁 278-280,496-497

有紀錄不等於操作成功，更不等於已啟用

05.02.ET02 包含舊版本 OFR、要求的新版本 NFR、Commit Action、slot，以及 Firmware Commit 的 SCT／SC。它是在命令完成時記錄，完成可能帶有錯誤，或表示還需要某種 reset 才能啟用。先讀命令結果，再看後續 ET04 的 FREV 與 FA，才能把「提出更新」與「重設後真正生效」接起來。

SCT: Status Code Type，完成狀態所屬的類型。
SC: Status Code，指定SCT類型內的結果代碼。

一筆重設事件可能涵蓋多個控制器

05.03.ET04 先有 8-byte FREV，後面不是固定一份資訊，而是多個 36-byte 描述子。每份有 CNTLID、FA、當時是否進行 Format、控制器電源循環次數、累積通電毫秒與事件時間。外層 CNTLID 指這筆事件的記錄者，內層各 CNTLID 才指出每份描述子對應誰；不能以為整筆只談外層那個控制器。

時間軸為什麼可能向後跳

05.04.Timestamp 是 48-bit 毫秒數加上屬性。Origin=0 是從控制器重設後的起點計時；Origin=1 表示主機設過時間，仍不能直接保證它是真實世界的 UTC。主機可能調整時鐘，新的數字比舊的更小；ET03 的 PTSTP 與 MSR 正是讓你辨認這種變更。SYNC=1 還表示計時可能曾暫停。

事件順序也要尊重來源邊界

05.05.規格建議較新的事件放在較小 offset，但具體排序方式由廠商決定。不同控制器可能有不同時間基準，時間也可能被改過；因此不要只用 ETSTP 大小重新排序後，就宣稱得到全 subsystem 嚴格一致的因果順序。先保留原始順序，再用 reset、時間變更與事件內容說明能建立的關係。

閱讀相關規格圖表 → 韌體、時間戳與重設要連著讀

06 把 namespace 變更接到 NVM 格式欄位

06.01.ET06 記錄成功的 Namespace Management 命令。Base Figure247 定義整體內容與欄位來源；NVM Figure112 補定 byte32 的 FLBAS 與 byte33 的 DPS：建立時取主機指定值，刪除單一 namespace 時取該 namespace 的 Identify 值，刪除全部時這兩個欄位保留。

來源：NVM Command Set 1.3 §4.1.4.4

來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.4, 文件頁 76-77, PDF 頁 76-77

06.02.ET07 在 Format 參數驗證後、修改媒體前記錄；ET08 在已修改媒體的 Format 完成時記錄，完成可以失敗。FNVMS 的 INCPLTF=1 表示已修改部分或全部資料卻未成功，也要求 FNVME=1。SFPI 是曾回報的最小剩餘百分比；全體 namespace 的 Format 則為0，不能單憑0判成功。

來源：Base 2.4 §5.2.13.1.14.2.6; 5.2.13.1.14.2.7; 5.2.13.1.14.2.8

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.6; 5.2.13.1.14.2.7; 5.2.13.1.14.2.8, 文件頁 258-261, PDF 頁 284-287

06.03.FLBAS 的 format index 由 bits6:5 與 bits3:0 組合，bit4 選 metadata 傳輸方式；DPS bits2:0 選保護資訊類型。NVM 1.3 的 DPS.PIP 必須為0，把啟用的保護資訊放在 metadata 尾端。Format index 只是格式表的編號，本身不是 byte 大小。

metadata: 隨 logical block 儲存的附加資料，可包含資料保護資訊，也可有其他用途。

來源：NVM Command Set 1.3 §4.1.5.1; 4.1.6

來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.5.1; 4.1.6, 文件頁 85-87,112-113, PDF 頁 85-87,112-113

先看做了什麼，再決定其餘欄位能不能讀

06.04.ET06 的 NMCDW10 保留 Namespace Management 的命令參數，其中 SEL 區分 Create、Delete、Restore。建立成功時 NSID 是分配到的新識別值；刪除一份時是被刪除的識別值；刪除全部是 FFFFFFFFh。當事件表示刪除全部，NSZE、NCAP、FLBAS、DPS 等單一 namespace 欄位不具有可用內容，不能把裡面的0說成「刪除了一個大小0的namespace」。

NCAP: Namespace Capacity，任一時點最多可配置給 namespace 的 logical blocks。
NSZE: Namespace Size，namespace 的總 logical block 數，LBA 範圍為 0 到 NSZE−1。
SEL: Select，Get Features 用來選 current、default、saved 或 supported-capabilities view 的欄位。

Base 負責外框，NVM 補上兩個洞

06.05.Base 表先告訴你 byte32、33 是由 command set 定義的欄位。NVM Figure112 才告訴你怎麼取得 FLBAS 與 DPS。這兩個 bytes 在事件裡的位置固定，但資料原本在 NVM Identify 或 Create 資料結構的 byte26、29。複製進事件後位置改了；如果仍到事件的 byte26 找 FLBAS，讀到的是 NCAP 的一部分。

Create取主機輸入、單一Delete取NVM Identify，兩者的FLBAS／DPS來源位置相同。Delete All則保留，不能做這種有效值解讀。來源：Base247；NVM112、123、134。

PI: Protection Information，用於檢查資料完整性及關聯資訊的保護資料。

用數值分清容量與格式

06.06.NSZE 與 NCAP 用 logical blocks 計算，不是 bytes。假設 NSZE=1000、NCAP=800，已知所選格式為4096 bytes資料加8 bytes metadata：可定址範圍是LBA0～999，可配置上限是800 blocks。若 FLBAS bit4=1，單一延伸區塊傳輸資料加metadata共4104 bytes；bit4=0時metadata另放buffer。範例的格式內容是另行給定，不是從format index的數字猜來。

建立、格式化與格式化結果分開

06.07.Namespace Management 是儲存物件的建立或刪除；Format 則是媒體格式操作。ET07 留下開始時的 NSID、FNA、CDW10；ET08 留下結果與進度。若 FNA 表示一次影響所有 namespace，命令指定其中一個 NSID 也不能把它理解成只改一份。看到開始事件，還不足以證明完成；看到完成事件，也還要檢查 FNVMS。

CDW: CDW（Command Dword）；命令中的 32-bit 欄位單位，例如 CDW10 的 10 是欄位 index，不是 byte offset。

閱讀相關規格圖表 → 把 namespace 變更接到 NVM 格式欄位

07 把清除開始、完成與媒體驗證分開

07.01.ET09 記錄 sanitize 進入處理狀態，ET0A 記錄進入 Idle 或失敗狀態；成功的命令完成不等於長時間清除已完成。ET0E 記錄進入 Media Verification，ETR=1、EL=0，沒有 ED。Start／Completion 的 NSID 指定清除對象，FFFFFFFFh 表示整個 subsystem。

來源：Base 2.4 §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14, 文件頁 261-262,266, PDF 頁 287-288,292

07.02.SPROG 的進度刻度是65536；FFFFh也可能出現在 Media Verification 或非處理狀態，所以要同時讀SSTAT.SOS。SOS=3表示失敗，1表示成功完成，4表示成功但發生了未要求的deallocation，2涵蓋處理中、驗證與驗證後deallocation。

SOS: Status of Sanitize Operation，SSTAT內表示清除操作狀態的代碼。

來源：Base 2.4 §5.2.13.1.38

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, 文件頁 314-316, PDF 頁 340-342

清除操作比命令生命週期長

07.03.主機送出 Sanitize，控制器可以先成功完成這個啟動命令，再花較長時間處理媒體。PEL 的開始與完成事件是記錄清除操作走到哪個狀態，不是把同一個 CQE 重複保存兩次。開始事件保存當時的 SANICAP 與啟動參數，幫你辨認使用的是 block erase、overwrite 或 crypto erase。

SANICAP: Sanitize Capabilities，清除方法、驗證及回報的支援能力。
CQE: Completion Queue Entry，CQ 中的一筆完成結果資料結構。

相同事件類型仍要比對清除對象

07.04.新格式的 ET09、ET0A 都有 NSID。若一筆指向namespace7，另一筆指向FFFFFFFFh，不能只因時間相近就宣稱是一對。兩種事件沒有提供通用的作業流水號；必須結合對象、時間與記錄上下文判讀。歷史可能有淘汰或抑制，更不能要求每個start一定都能在手上這份資料找到completion。

清除事件的名稱，與它真正證明的進度

看到的紀錄	可確認的事	還不能說的事
09h Start	進入清除處理；保存參數與NSID	清除已完成
0Eh Media Verification	已進入媒體驗證；沒有ED	已成功完成；ED內有NSID
0Ah Completion + SOS3	操作已進入失敗狀態	SPROGFFFFh就等於成功
0Ah Completion + SOS1	此次操作成功完成	之後永遠沒有新資料寫入

這是結論對比，不是保證每份PEL都包含完整事件配對。來源：Base §§5.2.13.1.14.2.9、.10、.14。

完成事件的名字不是成功保證

07.05.ET0A 包含 SPROG、SSTAT、CINFO 和 NSID。SSTAT 裡的 SOS 才告訴你是成功、失敗還是其他狀態。CINFO 是廠商補充原因，沒有通用碼表；它不能取代 SOS。尤其 SPROG=FFFFh 在多種情況都可能出現，不能直接換算成「已安全清完100%」。

進入驗證是一個節點，不是另一份進度表

07.06.ET0E 的事件總長仍包含共同 header，但沒有 ED，因此也沒有自己的 NSID、SPROG 或 SSTAT 可讀。這個事件只證明進入了 Media Verification。若後續驗證被取消或清除失敗，仍需依其他事件與狀態辨認，不能替空的 ED 補想像中的欄位。

閱讀相關規格圖表 → 把清除開始、完成與媒體驗證分開

08 先選硬體錯誤代碼，再選附加資料格式

08.01.ET05 的 NSHEEC 選擇硬體錯誤種類，AHEI 的格式與長度跟著種類改變。01h～03h 是 PCIe 錯誤資訊，08h 是非預期斷電資訊，0Bh 是控制器就緒逾時資訊；某些種類沒有 AHEI。硬體事件子類的支援由廠商決定，不能把固定的一張表套到所有 ET05。

NSHEEC: NVM Subsystem Hardware Error Event Code，ET05內選擇硬體錯誤子類的代碼。
AHEI: Additional Hardware Error Information，依硬體錯誤子類選擇格式的附加資訊。
PCIe: PCI Express，NVMe memory-based controller 使用的 transport 與裝置互連。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, 文件頁 254-258, PDF 頁 280-284

把兩層種類分開

08.02.外層 ET=05h 只表示是 hardware error。進入 ED 後還要讀 NSHEEC，才能決定後面 AHEI 是哪一種資料。這類結構像一封信的信封標「設備事件」，內頁再標「電源」或「連線」；後面的欄位要按內頁種類讀，不能因共同開頭相同就當成每封都裝同一種表。

警告、鏈路事件與命令錯誤有不同證據

08.03.Critical Warning 類型保留警告位元；Endurance Group 警告還帶 Group ID；media/data integrity 類型則帶完整 CQE。PCIe link status change 的附加資料是 Link Status 暫存器值，並不是PCIe錯誤類型那份80-byte AER結構。Link not active 和CSTS.CFS的類型沒有額外資料，沒有AHEI本身不是紀錄損壞。

Endurance Group: Endurance Group，用於隔離與回報耐久度相關狀態的 NVM 資源群組。
CSTS: Controller Status，controller 回報 ready、fatal status 與 shutdown 狀態的 property。
AER: Advanced Error Reporting，PCIe 用來分類、遮罩與記錄 link／transaction error 的 capability。

電源事件不能只看「不正常」三個字

08.04.Unexpected Power Loss 附加資訊有累計UPL與一個UPLOA位元。UPLOA描述一個很特定的情境：已在shutdown處理或完成狀態，卻因允許忽略shutdown的帶外管理操作讓媒體仍需運作，此時主電源掉落。UPLOA=0只表示不符合這個特殊標記，不表示這次掉電其實是正常關機。

就緒逾時要連同當時模式

08.05.控制器啟用後的等待限制跟 ready mode 有關。事件內的 CRIME 保存當時模式，CNR、ACMNR、NNR 分別指出控制器、Admin命令所需媒體、或附接namespace未及時就緒。這些位元可同時提供線索，不是四選一的錯誤等級；有一位為0也不表示其他範圍已正常。

Admin: Administrative，建立、設定、查詢或管理 controller 與 queue 的控制路徑。

閱讀相關規格圖表 → 先選硬體錯誤代碼，再選附加資料格式

09 設定事件如何保留命令與資料

09.01.ET0B 在成功 Set Features、值確實改變且支援記錄時必須記錄；成功但同值時可記錄。Figure252 的 O／P／NR 是各 Feature 在指定控制器類型上的記錄要求，不是該 Feature 的支援能力。SFEL 決定連續 CDW、可選資料 buffer 與可選 CQE DW0 的位置。

SFEL: Set Feature Event Layout，指明事件內命令、資料buffer與完成值的位置。
P: Phase Tag，讓 host 判斷 CQ slot 是否包含新 completion 的翻轉 bit。

來源：Base 2.4 §5.2.13.1.14.2.11

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, 文件頁 262-264, PDF 頁 288-290

09.02.ET0F 是 Configurable Device Personality 的專屬事件，描述設定變更、freeze／unfreeze或安全條件造成的freeze。CDPRFS記錄要求的freeze狀態，CDPCE表示變更錯誤；不能因requested bit=1就宣稱已成功freeze。Manufacturing Default請求只記一筆，不逐personality拆成多筆。

freeze: 凍結設定變更；事件中的請求狀態與實際成功結果需分開判讀。

來源：Base 2.4 §5.2.13.1.14.2.15

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.15, 文件頁 266-267, PDF 頁 292-293

先辨認記錄政策，不把O當成功

09.03.O是可選記錄，P是禁止記錄，NR是不建議記錄。選對I/O或Admin控制器欄位後再看Feature列。Timestamp在這張Set Feature表是P，因為有自己的ET03；因此「沒有ET0B的Timestamp紀錄」不能說主機從未改過時鐘。某Feature為O也不代表控制器一定會替它留下事件。

命令Dword數與buffer bytes分開算

09.04.SFEL的DWC直接計算幾個Dwords，1～6有效，沒有NUMD那種加1。從CDW10開始连續保存，直到最高的非保留命令Dword，中間即使某個Dword是保留也包含在內。MBC則以bytes計算後面的資料buffer；LCCDW0只有0或1，決定最後是否再有4-byte完成值。三種單位不能混算。

純格式算例DWC3、MBC8、LCCDW01，沒有假定某FID一定使用這些欄位。來源：Base Figure253。

FID: Feature Identifier；指定要讀取或設定哪一項 Feature 的編號。

完成DW0不是整份完成項目

09.05.這個可選欄位只保存Set Features的CQE DW0，不是16-byte CQE，也不是其中的Status欄。先用SFEL找到它，再按那個Feature的回覆意義讀；若LCCDW0=0，這個位置根本沒有欄位，不能把下一笔事件的頭當成完成值。

Personality事件不是Set事件的改名

09.06.ET0F把請求狀態PS、PERID與personality專屬資料PED分開。PED從byte12開始，內容由PERID指定的personality定義；共同格式本身沒有提供一套適用所有personality的欄位。讀者至少能確定請求freeze與否、有沒有change error、針對哪個personality，以及保留的原始專屬資料長度。

PS: Power State，controller 的功耗／效能 operating point；PS0 是最高 maximum-power state。

閱讀相關規格圖表 → 設定事件如何保留命令與資料

10 識別值映射與廠商擴充如何讀到正確邊界

10.01.ET10 記錄 Exported NVM Subsystem 的建立、刪除或實體變更；OTYP 決定 EEID／UEID 代表namespace、controller、port或其他對象。ETDE 的 ED 是一串廠商資料描述子，每筆長度為6+VSEDL，依VSEDT選資料型別；廠商事件與任何事件皆可能有的VSI並不是同一層。ETDF的內容格式由TCG保留定義。

TCG: Trusted Computing Group；此處Base把特定安全事件內容保留給其定義。

來源：Base 2.4 §5.2.13.1.14.2.16; 5.2.13.1.14.2.17; 5.2.13.1.14.2.18

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.16; 5.2.13.1.14.2.17; 5.2.13.1.14.2.18, 文件頁 267-270, PDF 頁 293-296

同一個實體可以有兩套編號

10.02.Exported NVM Subsystem是在底層資源之上呈現的儲存子系統；PEL記錄其中實體對應關係的改變。假設Exported namespace5對應Underlying namespace42，EEID=5、UEID=42描述的是同一映射的兩端，不是兩個互相競爭的namespace ID。OTYP=2表示新增namespace，4則改成新增controller，解讀欄位前先確認種類。這裡只教事件內的映射，不展開傳輸或建立流程。

廠商事件有自己的內部串列

10.03.共同事件header後可能先有VSI，再有ETDE的ED。ED內又是一筆筆小描述子，每筆有VSEC、VSEDT、UIDX、VSEDL與VSED。前面的VSI大小由VSIL管；內部資料大小由各自VSEDL管。不要看到兩個都寫vendor就合在一起，也不要把外層EL當作每一筆內部描述子的長度。

UIDX: UUID Index，指向 UUID List 位置的 index；0 表示未指定 UUID。

先讀型別，再決定怎樣顯示

10.04.VSEDT=1是以零字元結尾的事件名稱，若存在必須第一筆；2是其他ASCII字串；3是二進位，byte order由廠商定義；4是64-bit有號整數，使用二補數。原始bytes全是FF，在型別4可代表−1，在型別3卻不應自動當−1。VSEC由廠商定義，同類事件必須使用一致的碼；UIDX記錄事件當時的UUID索引。

UUID: Universally Unique Identifier；索引用來選擇對應的廠商資料定義。

能確認外框，不代表能憑空解出廠商意義

10.05.沒有廠商資料定義，仍能確認每筆描述子的範圍、資料型別、原始值及名稱，但不能編造某個VSEC表示哪種故障。同樣地，ETDF只在本份Base規格中保留給TCG定義事件版本與內容；可以按共同外框辨認並保留這笔事件，不能拿ETDE的描述子規則套上去。

閱讀相關規格圖表 → 識別值映射與廠商擴充如何讀到正確邊界

11 讀懂本篇的規格圖表

11.01.以下依概念整理規格中的圖表。每組先說明讀取順序與要判斷的問題，接著列出各圖的欄位或行為說明。可以由正文的連結跳到對應組別，也可以用這一節檢查自己能否把欄位連回完整操作。

圖表組 01 · 先分清事件歷史、目前狀態與完整性 · 2 張圖表

11.02.Figure 233 看實際回報；Figure 236 看事件分類；Figure 338 只取相關能力。

回到本節的解釋與範例

把類型、記錄要求與內容版本對照

11.03.M/O的前提是支援PEL；本篇只呈現PCIe相關要求。事件子類的記錄門檻與廠商抑制規則仍同時適用。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
01h SMART；02h FW；03h Timestamp；04h Reset	01在PCIe情境必備；02～04必備。這四類ETR=1。	必備種類不等於這次TNEV必須含每一種，仍要有相應觸發。
05h Hardware；06h Namespace；07h／08h Format	05必備，ETR2；06與07／08在起因命令受支援時必備。06／08用ETR2，07用1。	ETR1的07與ETR2的08不可因同是Format而套相同表。
09h／0Ah Sanitize	起因命令受支援時必備，兩者ETR2。	NSID位於新內容裡；讀舊ETR不能直接假設有它。
0Bh／0Ch／0Dh／0Eh／0Fh／10h／DEh	均選用、ETR1；依次為Set Feature、Telemetry、Thermal、Verification、CDP、Exported Change、Vendor。	選用指不一定支援；支援後仍須遵守該事件的觸發規則。
DFh與保留代碼	DFh選用，其ETR與ED保留給TCG定義。00h、11h～DDh、E0h～FFh保留。	未知碼不解成最近的已知事件；DFh也不套DEh描述子。

CDP: Configurable Device Personality，可設定的裝置運作特性組合。

來源：Base 2.4 §5.2.13.1.14.2

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2, Figure 236, 文件頁 251, PDF 頁 277

Base Figure 236 · Persistent Event Log Event Types

一句話重點

Base236-1支援要求與ETR分別回答「要不要有」和「怎麼解」。

來源：Base 2.4 §5.2.13.1.14.2

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2, Figure 236, 文件頁 251, PDF 頁 277

用例子讀懂

Base236-2ET08的ETR2是新版Format Completion格式，不是第2筆Format事件；ET0E雖沒有ED，仍是有效的選用事件種類。

欄位、條件與相關細節：把類型、記錄要求與內容版本對照 →

只補PEL事件用到的Identify欄位

11.04.Figure338是長表，本篇只取LPA／PELS、溫度門檻、FNA及SANICAP；其他能力未因此全部納入。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
LPA byte261：PES bit4、LPEDS bit2	PES1支援PEL；LPEDS1支援extended Get Log長度與offset。PELS bytes355:352以64KiB為單位表示最大PEL大小。	PELS4=4×65536=262144 bytes，不是TLL固定值。
WCTEMP267:266；CCTEMP269:268	警告與嚴重綜合溫度門檻，Kelvin；0未提供門檻，Base1.2以上應回非零。	讀THRESH1／2時選相應門檻，不把這兩個值加在一起。
FNA byte524	來源是Identify Controller；bits3:0的完整作用在Format欄位組統一說明。	Figure248保存的FNA只佔一byte，不是Namespace Identify整份資料。
SANICAP331:328：bits2:0	OWS bit2、BES bit1、CES bit0分別支援overwrite、block erase、crypto erase。	值6支援overwrite與block erase，不支援crypto erase。
SANICAP bits3／4／5	VERS bit3為subsystem驗證狀態支援；NVERS bit4為namespace驗證支援；SPRRS bit5為Purge要求／回報支援；bits28:6保留。	VERS與NVERS不互相代替；PREQ只有SPRRS支援時才有定義。
SANICAP NDI bit29	1表示NDAS不一定可保留allocation：回應模式NODRM1時仍deallocate；NODRM0或無該Feature時，NDAS1被拒絕。NDI0支援NDAS；NDAS0時NDI不改變處理。	Start保存NDAS1，不足以單獨斷言作業後一定沒deallocate。
SANICAP NODMMAS31:30	描述NDAS1時清除處理是否另外修改媒體：0舊版／不支援時未定義，1不額外修改，2會額外修改，3保留。	這是額外媒體修改行為，不是某一種sanitize方法的成功碼。

來源：Base 2.4 §5.2.14.2.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 355,357,361-362,364,373, PDF 頁 381,383,387-388,390,399

Base Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent

一句話重點

Base338-1Identify提供的是能力與上限；事件內保存的副本則反映當時值。

來源：Base 2.4 §5.2.14.2.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 355,357,361-362,364,373, PDF 頁 381,383,387-388,390,399

用例子讀懂

Base338-2LPA bit4=1但PELS4，不表示只有4筆事件；它表示支援PEL且最大256KiB。當時保存的SANICAP和今天查到的能力，也不應不加區別地互換。

欄位、條件與相關細節：只補PEL事件用到的Identify欄位 →

圖表組 02 · 用 reporting context 取得同一份紀錄 · 11 張圖表

11.05.Figures 232／235 分開教命令動作與支援宣告；233 的 RCI／GNUM 說明 context 狀態。

回到本節的解釋與範例

外層命令怎麼組成一次讀取

11.06.Figures203～211只取PEL所需格式與LID0Dh列。byte offset、Dword計數、事件index是三種不同單位。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
DPTR；NSID	DPTR指向主機接收buffer；subsystem範圍只用NSID0或FFFFFFFFh，其他值回Invalid Field in Command。	NSID7不能拿來篩選只看namespace7的事件。
CDW10 NUMDL31:16、RAE15、LSP14:8、LID7:0	LID0Dh；LSP低2bits即ACT；RAE控制相應非同步事件確認，非此用途時應0。	命令裡ACT在bits9:8；ECRH能力則是另一個資料結構的bit。
CDW11 NUMDU15:0、LSI31:16	NUMD=(NUMDU<<16)\|NUMDL，bytes=4×(NUMD+1)。PEL未定義LSI作篩選。無extended支援時使用舊有低12-bit長度限制。	512bytes→NUMD127；NUMD128→516bytes。
CDW12 LPOL、CDW13 LPOU	合成64-bit位置；OT0時以bytes計、低2bits0保持Dword對齊。ACT2／3特例忽略此位置。	讀第512byte開始用LPO512；一筆事件可以跨兩次傳輸。
CDW14 OT23、CSI31:24、UIDX6:0	OT0為byte、1為index且須該log的IOS支援與定義；PEL的CSI不使用。UIDX0未選UUID，1～127選清單項目；bits22:7保留。	不因log含很多事件就自行假設index模式可用；本篇流程固定OT0。
Supported Log Pages bytes55:52	LID0Dh第13項；每項4bytes，LSUPP bit0先判斷支援，IOS bit1判斷index offset，LIDSP31:16放ECRH等專屬能力；bits15:2保留。	00010001h把ECRH放bit16，不能把它寫成bit0而覆蓋LSUPP。
Figure209的Restore to Default Content欄	PEL列為N，描述指定的出廠設定復原，不是一般reset的通用持續性欄。	跨power cycle／reset保留的依據是PEL正文，不能只讀這個N。

NUMDL: Number of Dwords Lower，Get Log Page 的 NUMD 低 16 bits。
NUMDU: Number of Dwords Upper，Get Log Page 的 NUMD 高 16 bits。
DPTR: Data Pointer，SQE 中指出 command data buffer 的欄位。
ECRH: Establish Context and Read Header，支援ACT3及GNUM的能力位。
LPOL: Log Page Offset Lower，Get Log Page byte offset 的低 32 bits。
LPOU: Log Page Offset Upper，Get Log Page byte offset 的高 32 bits。
CSI: I/O Command Set Identifier；選擇 I/O 命令集，NVM Command Set 使用 00h。
LSI: Log Specific Identifier，意義由所選 log page 定義的 identifier。
LSP: Log Specific Field，意義由所選 log page 定義的 command selector。
RAE: Retain Asynchronous Event，Get Log Page 是否保留相關 asynchronous event 的 selector。

來源：Base 2.4 §5.2.13 · Base 2.4 §5.2.13.1.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 203, 文件頁 213, PDF 頁 239

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240

Base211-1先確認LSUPP，再看IOS與LIDSP，不能把未支援列的其他bits當能力。

來源：Base 2.4 §5.2.13.1.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.1, Figure 211, 文件頁 217-218, PDF 頁 243-244

用例子讀懂

Base211-2描述子00010001h是LSUPP1、IOS0、LIDSP1：支援PEL與ECRH，但未宣告index offset。

欄位、條件與相關細節：外層命令怎麼組成一次讀取 →

四種動作與一個能力位

11.07.Figure232使用CDW10內的LSP bits9:8；Figure235使用能力描述子的LIDSP bit0，位置與用途不同。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
ACT=0：Read	讀既有context；從LPO指定位置開始。沒有context時回Command Sequence Error。	分段讀取的第二段用ACT0，不重建事件集合。
ACT=1：Establish and Read	先決定回報集合與長度，建立context後讀取；已存在時失敗。	NUMD127、LPO0可先讀512-byte header。
ACT=2：Release	釋放已有context；沒有也不算錯，不回log data，忽略NUMD與LPO。	不是清除持久事件；配置更大的buffer也不會讓它讀回事件。
ACT=3：Establish or reuse + Header	不存在就建立，存在則沿用；均成功回offset0的512 bytes。忽略NUMD與LPO，buffer至少512 bytes。	RCE0是原先不存在；成功之後已建立，接續用ACT0。
ECRH與保留位	能力LIDSP bit0=1支援ACT3與GNUM；bits15:1保留。支援PEL且符合Base2.0以上時須為1。ACT所在的LSP bits14:10保留。	先確認支援，不能把能力值寫到命令的錯誤bit位置。

來源：Base 2.4 §5.2.13.1.14 · Base 2.4 §5.2.13.1.14.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, Figure 232, 文件頁 246, PDF 頁 272

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.1, Figure 235, 文件頁 251, PDF 頁 277

Base Figure 232 · Persistent Event Log Specific Parameter Field

一句話重點

Base232-1ACT選擇的是context動作，不是想讀哪一種事件。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, Figure 232, 文件頁 246, PDF 頁 272

用例子讀懂

Base232-2ACT3成功回RCE1表示沿用已有context；ACT1在同樣已有context時卻回Command Sequence Error。這兩種建立動作不是同義詞，不能只因名稱都含Establish就互換。

欄位、條件與相關細節：四種動作與一個能力位 →

Base Figure 235 · Persistent Event LID Specific Parameter Field

一句話重點

Base235-1ECRH在Supported Log Pages的能力描述子內，並不放在PEL事件header。

來源：Base 2.4 §5.2.13.1.14.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.1, Figure 235, 文件頁 251, PDF 頁 277

用例子讀懂

Base235-2LID0Dh的描述子若LIDSP bit0=1，表示可以使用ACT3與GNUM；這個1不是ACT1，也不是PEL header的RCE1。

欄位、條件與相關細節：四種動作與一個能力位 →

圖表組 03 · 從 header 走到每筆事件的邊界 · 2 張圖表

11.08.Figures 233／234 的 bytes 欄是相對位置；Figure 236 的 ET 是代碼，兩者不是同一種數字。

回到本節的解釋與範例

整份報告的header：先讀長度，再讀來源與支援

11.09.所有位置相對log起點；本版header共512 bytes。未展開的識別資料仍佔原位，不能刪掉其bytes後重算後續offset。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
LID byte0；TNEV bytes7:4；TLL15:8	LID=0Dh；TNEV是直接筆數；TLL含header的總bytes。bytes3:1保留。	TNEV9代表9筆，不是0-based的10筆。
LREV byte16；LHL19:18	本版LREV=03h；byte17保留。header長度=LHL+20，當前LHL=492。	LREV3不能代替事件自己的ETR。
TSTMP27:20；POH43:28；PWRCC51:44	TSTMP是context建立時間，格式見Timestamp組。POH為取log時power-on hours，可不含非運作狀態；PWRCC為控制器電源循環次數。	TSTMP與單筆ETSTP回答不同時間；不能把POH當毫秒。
VID53:52；SSVID55:54；SN75:56；MN115:76	分別為PCI廠商識別、副系統廠商識別、20-byte序號、40-byte型號。	這些資訊辨認記錄來源，不是某筆事件的NSID。
bytes371:116	本篇不展開的識別資料，佔256 bytes；不是保留區，也不是零長度。	GNUM仍從372開始，不得前移到116。
GNUM373:372	建立新context且內容相較上一份改變才遞增；FFFFh加1回0。	ACT0多讀幾次不使GNUM每次加1；相等也不意味可忽略context重設條件。
RCI377:374：RCE bit18	回報命令處理前是否已有context；RCE0時RCPIT與RCPID清0。bits31:19保留。	ACT3新建成功可回RCE0。
RCI：RCPIT bits17:16、RCPID15:0	RCPIT0無既有context資訊；1是subsystem port；2是Management Endpoint，RCPID低byte為其port、高byte0；3保留。	RCPIT2、RCPID0005h是管理入口5，不是控制器CNTLID5。
SEB511:480；bytes479:378保留	256-bit支援bitmap。bit1～15依次是SMART、FW、時間、reset、hardware、namespace、format start／complete、sanitize start／complete、Set Feature、telemetry、thermal、verification、CDP；222=DEh廠商、223=DFh TCG。	bit6=1表示支援Namespace Change，不表示目前有6筆事件。
SEB與ET10h的來源差異	本版Figure233仍把bits221:16列為保留，但Figure236與後文已定義ET10h。兩處不一致，不能自行宣稱SEB bit16是ET10h能力位。bit0與bits255:224也保留。	可以按ET10h的已定義格式讀取實際事件；不捏造一個尚未定義的能力bit。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, Figure 233, 文件頁 247-249, PDF 頁 273-275

Base Figure 233 · Persistent Event Log Page

一句話重點

Base233-1TLL是整份長度，TNEV是事件筆數，LHL要加20才是header大小。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, Figure 233, 文件頁 247-249, PDF 頁 273-275

用例子讀懂

Base233-2LHL=492時header=512 bytes；TNEV=0仍有header。若TLL=556而第一筆總長44，就由offset512走到556，剛好到資料尾端，而不是再找第二筆。

欄位、條件與相關細節：整份報告的header：先讀長度，再讀來源與支援 →

單筆事件的共同外框

11.10.以下offset相對這筆事件起點；目前共同header24 bytes，但解析仍依EHL+3。外層EL與內層各資料長度不可互換。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
ET0、ETR1、EHL2	ET選種類，ETR選內容版本；EHL只計前3 bytes之後的header長度。	EHL21得到24；ET05／ETR2應用新版硬體事件格式。
EHAI3：PIT bits1:0	0未回報port類型；1subsystem port；2Management Endpoint；3未關聯port。Base2.0以上要求非0；bits7:2保留。	PIT3是已明確說無port，不等於舊格式的未回報。
CNTLID5:4；ETSTP13:6	CNTLID為建立紀錄的控制器；控制器專屬事件指該控制器，否則是subsystem選定的記錄者。ETSTP為發生時間。	共同header的CNTLID不保證等於ED內每一個描述子的CNTLID。
PELPID15:14；19:16保留	PIT0／3時為0；PIT1時為subsystem port ID；PIT2時低byte為管理端點port ID、高byte0。	先讀PIT才能解PELPID；0007h不是必然指namespace7。
VSIL21:20；EL23:22	VSIL是廠商附加bytes數；EL是VSI加ED的bytes數。無VSI時VSIL0。	VSIL4、EL20，ED只有16。
VSI起點EHL+3；ED起點EHL+3+VSIL	VSI可省略，ED也可不存在；下一筆起點加EHL+3+EL。	ET0E／EL0仍有24-byte共同header，沒有ED，也沒有VSI。
TLL、TNEV與未知版本	依長度走訪事件，同時核對筆數與總邊界；未知內容不按已知格式猜欄位。	傳輸可以涵蓋半筆事件，應組合足夠bytes後再讀；不能自行把每筆補成4-byte倍數。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, Figure 234, 文件頁 249-250, PDF 頁 275-276

Base Figure 234 · Persistent Event Format

一句話重點

Base234-1EL已包含VSI；用EHL+3+EL前進，才會落在下一筆事件開頭。

來源：Base 2.4 §5.2.13.1.14

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, Figure 234, 文件頁 249-250, PDF 頁 275-276

用例子讀懂

Base234-2另一個例子：事件起點1024、EHL21、VSIL0、EL12，沒有VSI，ED從1048開始且長12，下一筆1060。此時ED緊接header，不保留一段空的VSI槽位。

欄位、條件與相關細節：單筆事件的共同外框 →

圖表組 04 · 健康、Telemetry 與溫度各留下什麼證據 · 8 張圖表

11.11.Figures 237／254／255 分別對應完整健康快照、Telemetry header 與溫差事件。

回到本節的解釋與範例

從快照外框讀進SMART欄位

11.12.Figure237的ED bytes511:0整份依Figure213；這裡按讀值用途分組，不要求以表內順序背誦。保留區不能當成額外sensor。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
CW byte0；EGCWS6；INFW7	CW bits0備用容量、1溫度、2可靠度、3全媒體唯讀、4揮發性備援、5持久記憶區唯讀／不可靠、6personality不確定，bit7保留。EGCWS bits0／2／3為任一Group的容量／可靠度／唯讀警告，其餘保留。INFW bit0為輸入電壓過高或過低，其餘保留。	多個警告可同時1；CW不是單選錯誤代碼，也不是單一namespace寫入保護設定。
CTEMP2:1；AVSP3；AVSPT4；PUSED5	CTEMP是廠商計算的綜合Kelvin溫度；AVSP／AVSPT為0～100%。PUSED是壽命估計，100不必然失效，可超過100，超過254以255表示，運作時按power-on hour更新。	PUSED105表示估計使用量超過額定基準，不是105%讀取失敗率。
DUR47:32；DUW63:48	以1000×512-byte單位向上取整，不含metadata；0表示未回報。	DUR3對應2001～3000個512-byte資料單位，不能宣稱精確1500KiB。
HRC79:64；HWC95:80	已完成的Host Read／User Data Out類命令數；具體命令歸類由command set決定。	一次命令可以傳很多blocks；命令計數不能直接換成bytes。
CBT111:96；PWRC127:112；POH143:128	CBT以分鐘計控制器忙於I/O的時間；PWRC為電源循環次數；POH以小時計，可能不含非運作狀態。	I/O重疊時CBT不是把每筆命令延遲相加。
UPL159:144；MDIE175:160；NEILE191:176	UPL累計非預期斷電；MDIE累計未復原資料完整性錯誤；NEILE是終生Error Information log entries數。	不把NEILE當作這份PEL的TNEV，也不由UPL推算掉電持續多久。
WCTT195:192；CCTT199:196	以分鐘計警告／嚴重溫度時間。WCTT一般為WCTEMP≤T<CCTEMP，配置遲滯時含遲滯時間；WCTEMP或CCTEMP為0時WCTT0，CCTEMP0時CCTT0。	CTEMP是溫度，WCTT是時間，不可互相比大小。
TSEN1～8：bytes215:200	每個佔2 bytes，0未實作；非0按Kelvin讀，對應Figure214。	第3顆sensor起offset204，index與byte offset不要混淆。
TMT1TC219:216／TMT2TC223:220	分別為兩種主機熱管理門檻的轉換次數，32-bit飽和；0可以是未啟用或沒發生。	計數2不是設定溫度2K。
TTTMT1 227:224／TTTMT2 231:228	分別以秒計兩種熱管理動作累積時間，32-bit飽和。	這裡60是60秒，與WCTT60分鐘不同。
OLEC239:232；IPM243:240	OLEC是向上取整的終生Wh，0未回報、64-bit飽和。IPM bits23:20為測量類型，bits17:16 scale：0未回報、1=0.0001W、2=0.01W、3保留；bits15:0數值。其餘bits保留。	IPM scale2、value350表示3.50W；不能把OLEC與IPM當同單位。
保留區與快照頻率	bytes31:8、511:244保留；其他計數通常以128-bit保存，個別欄位上列寬度優先。ET01間隔≤24 power-on hours；虛擬化時對primary controllers記錄。	斷電兩天不等於必須額外新增兩筆每日快照。

Host: 主機；執行作業系統並送出 NVMe 命令的一端。

來源：Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.14.2.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3, Figure 213, 文件頁 221-225, PDF 頁 247-251

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3, Figure 214, 文件頁 225, PDF 頁 251

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1, Figure 237, 文件頁 252, PDF 頁 278

Base Figure 213 · SMART / Health Information Log Page

一句話重點

Base213-1SMART同時有狀態、累計量與時間，零值與單位必須逐欄判斷。

來源：Base 2.4 §5.2.13.1.3

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3, Figure 213, 文件頁 221-225, PDF 頁 247-251

用例子讀懂

Base213-2Data Units Read=3代表向上取整後的1000×512-byte計量；Controller Busy Time=3卻是3分鐘。把兩個3放在同一條「使用量」軸會失去意義。

欄位、條件與相關細節：從快照外框讀進SMART欄位 →

Base Figure 214 · Temperature Sensor Data Structure

一句話重點

Base214-1每個溫度sensor是16-bit Kelvin值，0代表沒有實作。

來源：Base 2.4 §5.2.13.1.3

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.3, Figure 214, 文件頁 225, PDF 頁 251

用例子讀懂

Base214-2Sensor1=300、Sensor2=0：前者約26.85°C，後者不是−273.15°C的實際測量；sensor位置與精度由廠商決定。

欄位、條件與相關細節：從快照外框讀進SMART欄位 →

比較兩種Telemetry header的相同與不同

11.13.Figures221／223只取前512 bytes，正好是Figure254保留的TIL；原始後續資料blocks不納入本事件。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
LID0；IEEE7:5	LID07h為Host-Initiated，08h為Controller-Initiated；IEEE為能解資料的廠商OUI，0未提供。bytes4:1保留。	先看07／08，才決定byte381應當作generation或scope。
DA1LB9:8、DA2LB11:10、DA3LB13:12、DA4LB19:16	皆為512-byte block的最後編號；非空從block1開始。DA2≥DA1、DA3≥DA2；支援DA4時DA4≥DA3。DA1=0表示無資料；15:14保留。	DA3LB9代表資料範圍1～9，不含header block0；資料區是重疊擴大集合。
Host header：THS380、THDGN381	THS0未回報、1controller、2subsystem，Base2.0以後版本不允許0，其餘保留。THDGN每次擷取遞增，FFh回0。bytes379:20保留。	THDGN是8-bit，不是PEL的16-bit GNUM。
Controller header：TCS381；bytes380:20保留	TCS的0／1／2與THS同義，但位置不同。	不能把Host的THDGN7，套Controller表讀成非法scope7。
共同：TCDA382、TCDGN383	TCDA1表示自上次RAE0成功讀取後有更新，0表示沒有未確認更新；Base2.4不能以0推論無saved state。TCDGN每次擷取完成後遞增，FFh回0。Host header只是複製這兩個Controller值。	PEL保留的是事件時副本；讀取PEL不是在確認原08h通知。
RID511:384	128-byte廠商原因識別資料，用來辨認當時操作條件；不是通用錯誤文字。	相同RID可協助對照，但其內容解碼與唯一性不能自行保證。

OUI: Organizationally Unique Identifier，由 IEEE 配置給組織的 identifier 前綴。

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.12, Figure 254, 文件頁 264, PDF 頁 290

用例子讀懂

Base254-2TIL byte0=08h、TCDA3LB=9：它指向當時Controller-Initiated Telemetry的blocks1～9，但ET0C的ED仍只有512 bytes，沒有那些9個blocks。

欄位、條件與相關細節：比較兩種Telemetry header的相同與不同 →

門檻事件的兩個bytes

11.14.OTMP在byte0，THRESH在byte1；相對差值不是從0K起算。起因與門檻要一起讀。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
THRESH01h／02h	往上跨WCTEMP／CCTEMP到大於等於門檻；除頻率限制外須記錄。	warning門檻343K、OTMP5，可得到348K。
03h／04h／05h	TMT1較輕、TMT2較重的熱管理開始，或廠商熱管理開始；可記錄。	05h門檻由廠商決定，未知門檻就無法只靠差值算絕對溫度。
88h／89h	88h由過熱或過冷回到正常區間；89h在原先未到WCTEMP的情況下停止熱管理。	「回正常」與「停止一種管理動作」是不同條件。
B0h；F0h～FFh	B0h由高於under-threshold往下到小於等於門檻；F0h～FFh廠商自訂，其他未列值保留。	低溫跨門檻要考慮方向，不能把OTMP都加到WCTEMP。
OTMP	門檻與測量溫度的絕對差，單位Kelvin。	差5K等於差5°C；絕對348K才換成74.85°C。

TMT1: Thermal Management Temperature 1，較輕度 thermal-management threshold，單位 Kelvin。
TMT2: Thermal Management Temperature 2，較強 thermal-management threshold，單位 Kelvin。

來源：Base 2.4 §5.2.13.1.14.2.13

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.13, Figure 255, 文件頁 265-266, PDF 頁 291-292

Base Figure 255 · Thermal Excursion Event Data Format (Event Type 0Dh)

一句話重點

Base255-1THRESH決定事件類型，OTMP只是相對門檻的溫差。

來源：Base 2.4 §5.2.13.1.14.2.13

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.13, Figure 255, 文件頁 265-266, PDF 頁 291-292

用例子讀懂

Base255-2THRESH01h、WCTEMP343K、OTMP5表示往上越過warning時高出5K；THRESHB0h則是往下跨under-threshold，不能也一律用加法。

欄位、條件與相關細節：門檻事件的兩個bytes →

辨認功率測量的對象

11.15.Figure745只補SMART IPM的PMT。其他power measurement機制不在本篇展開。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
PMT0；1h～Bh；Ch～Fh	0為subsystem總功率；1～B保留；C～F廠商自訂。	是否有回報由IPM scale判斷，PMT0本身是有效類型。

來源：Base 2.4 §8.1.20

來源：NVME-BASE-2.4, Rev. 2.4, §8.1.20, Figure 745, 文件頁 678, PDF 頁 704

Base Figure 745 · Power Measurement Types

一句話重點

Base745-1Power Measurement Type說明量哪個對象，不決定Watt縮放倍率。

來源：Base 2.4 §8.1.20

來源：NVME-BASE-2.4, Rev. 2.4, §8.1.20, Figure 745, 文件頁 678, PDF 頁 704

用例子讀懂

Base745-2IPM.PMT0為subsystem總功率，PMTCh為廠商定義；scale2才表示每單位0.01W。把PMT0看成未回報會漏掉有效測量。

欄位、條件與相關細節：辨認功率測量的對象 →

圖表組 05 · 韌體、時間戳與重設要連著讀 · 7 張圖表

11.16.Figures 238～241 與 Timestamp Figure480 共用時間基準教學。

回到本節的解釋與範例

韌體提交的要求與結果

11.17.Figure238的ED長22 bytes；版本欄是8-byte版本資料，不能把它們當整數比較新舊。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
OFR7:0；NFR15:8	OFR為原先active版本，NFR為要求提交的新版本。	版本B字樣出現在NFR，只證明請求的版本。
FCA16；FSLT17	FCA為Commit Action；FSLT為slot。0取代不啟用、1取代並下次reset啟用、2選既有slot下次reset啟用、3立即啟用；6／7為Boot Partition相關動作，4／5保留。	FCA1與FCA3的啟用時點不同。slot0在命令中讓控制器選slot，不是編號0的固定槽。
STCTFCC18；SRFCC19；VAFCRC21:20	前兩者為該次Firmware Commit的SCT與SC；最後為廠商補充Firmware Commit結果碼，0表示無附加資訊。	SCT1、SC10h表示提交成功但需要subsystem reset；不是通用的成功且已啟用。
原命令CA bits5:3、FS2:0、BPID31	CA與FS提取後放到事件FCA、FSLT。BPID只供Boot Partition動作，bits30:6保留；事件未另設BPID欄。	0Ah=(1<<3)\|2，因此FCA1、slot2。
SCT1的相關activation完成碼	SC0Bh需Conventional Reset；10h需Subsystem Reset；11h需Controller Level Reset；12h表示啟用超過MTFA限制、未啟用。這些碼不同於SCT0／SC0。	不把任何含reset字樣的結果統稱同一種重設即可。

MTFA: Maximum Time for Firmware Activation，activation 可能暫停 command processing 的最長時間。
CA: Commit Action，Firmware Commit 中選擇 replace、activate 與 reset policy 的欄位。
FS: Firmware Slot，Firmware Commit 中選擇目標 slot 的欄位。

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.2, Figure 238, 文件頁 252, PDF 頁 278

用例子讀懂

Base238-2OFR=A、NFR=B、FCA=1，描述替換並選擇下次reset啟用B。即使提交成功，也還要等對應啟用時點，不能把B當成事件當下正在執行的版本。

欄位、條件與相關細節：韌體提交的要求與結果 →

把數值、起點和是否連續計時分開

11.18.Figure239只存前一時間與MSR；事件後時間在共同header。Figure480同時解釋TSTMP、ETSTP、PTSTP與CTSTP。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
Timestamp bytes5:0	48-bit毫秒值，計數回捲依2^48範圍；不能只讀低32bits。	5000ms=5秒；換算成日期前必須知道時間起點。
byte6 bits3:1：Origin	0從controller reset後的起點；1主機曾設定；其他值保留。	Origin1表示來源方式，不是時鐘校準保證。
byte6 bit0：SYNC	0計時連續；1可能有暫停計時區間。bits7:4及byte7保留。	SYNC1的兩筆差1000ms，不一定等於真實世界剛好過1秒。
Figure239 PTSTP7:0、MSR15:8	PTSTP用上述8-byte格式；MSR是距Controller Level Reset的毫秒數，不是另一份Timestamp結構。	MSR的高byte不能按Origin／SYNC讀。

來源：Base 2.4 §5.2.13.1.14.2.3 · Base 2.4 §5.2.30.1.8

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.3, Figure 239, 文件頁 253, PDF 頁 279

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.8, Figure 480, 文件頁 470-471, PDF 頁 496-497

Base Figure 239 · Timestamp Change Event Format (Event Type 03h)

一句話重點

Base239-1PTSTP是變更前，外層ETSTP是變更後，MSR才是從reset起算的間隔。

來源：Base 2.4 §5.2.13.1.14.2.3

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.3, Figure 239, 文件頁 253, PDF 頁 279

用例子讀懂

Base239-2PTSTP=90000ms、新ETSTP=5000ms、MSR=100000ms可以描述主機把時鐘調小；不能因90000大於5000就把事件順序顛倒。

欄位、條件與相關細節：把數值、起點和是否連續計時分開 →

先定清單長度，再逐控制器讀

11.19.Figure240的RIL是清單；Figure241是清單內每個36-byte項目。數量=(EL−VSIL−8)/36，前提是內容符合此ETR格式。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
FREV：ED bytes7:0	CC.EN由0到1時即將生效的韌體版本。後面所有bytes為RIL。	若版本A仍有效，不因先前NFR寫B就改報B。
描述子CNTLID1:0、FA2	CNTLID辨認控制器；FA0沒啟用、1啟用成功、2啟用失敗，其餘保留。	FA0不是「啟用失敗」；表示沒有做這個動作。
OIP3：RDNF bit0	記錄reset時是否有Format NVM進行中；bits7:1與bytes15:4保留。	RDNF1只說當時在進行，不回報Format最終結果。
CPWRC19:16；POM27:20	電源循環次數與累積power-on milliseconds；POM可能略過非運作狀態，解析度由廠商決定。	POM若只按小時更新，會以3600000的倍數呈現。
CTSTP35:28	各控制器的power-on／reset事件時間，使用Timestamp格式。	不同控制器的CTSTP數字不能不看時鐘來源就比較先後。

CC: Controller Configuration，host 用來選擇設定並啟用或停用 controller 的 property。
EN: Enable，CC 中控制 controller enable state 的 bit。

用例子讀懂

Base480-2Timestamp value5000、Origin0表示從reset後的時間基準計到5秒；Origin1才表示主機設過時間，但主機設的值也不保證是真實UTC。

欄位、條件與相關細節：把數值、起點和是否連續計時分開 →

圖表組 06 · 把 namespace 變更接到 NVM 格式欄位 · 9 張圖表

11.20.Base247 和 NVM112 應放一起讀；248／249 則是一個格式化操作的起點與結果。

回到本節的解釋與範例

開始參數與完成結果分別解讀

11.21.Figure248 ED共12 bytes，249新版ED也12 bytes，但相同offset並不是相同欄位。Figures195／NVM91只用來解保存的FMCDW10。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
Start：NSID3:0、FNA4、FMCDW10 11:8	NSID為命令目標，FNA保存Identify Controller能力，bytes7:5保留。	FNA是控制器能力，不能拿目前Identify Namespace某個同offset的byte替代。
FNA bits3:0	bit3 FNVMBS=1反而不支援FFFFFFFFh；bit2 CRYES為crypto erase支援；bit1 SENS控制secure erase是否影響全部；bit0 FNS控制一般format是否影響全部。bits7:4保留。	支援廣播與實際format影響全部是兩個問題。
FMCDW10：LBAFU13:12、LBAFL3:0	format index=(upper<<4)\|lower；Host Behavior LBAFEE0時忽略upper。bits31:14保留。	要知道歷史LBAFEE條件，才可把upper1與lower2解成18。
FMCDW10 SES11:9	0不要求安全清除；1User Data Erase，結果內容不保證全0；2Crypto Erase刪除金鑰；3～7保留。	SES1不保證採某一種物理擦除演算法，已加密資料可使用crypto erase完成。
NVM FMCDW10 PIL8、PI7:5、MSET4	PIL需0把PI放metadata尾端；PI0關閉、1／2／3類型、4～7保留；MSET1metadata延伸傳輸，0分開，metadata大小0時忽略。	CDW10=32h是index2、PI1、MSET1；FLBAS32h則是另一個編碼。
Complete：NSID3:0、SFPI4	SFPI為操作期間最小剩餘百分比；全體namespace操作強制0。	它是剩多少，不是做完多少；不以0獨立判斷成功。
FNVMS5：INCPLTF bit1、FNVME bit0	INCPLTF1表示已修改資料卻失敗，此時FNVME也須1；FNVME0表示成功，bits7:2保留。	03h是部分或全部資料已改動的失敗，不能安全假設資料原樣不變。
CINFO7:6；INFO9:8；11:10保留	CINFO廠商補充；INFO bits15:1保存CQE status若存在，無CQE時0；bit0可能保存Phase。	先看FNVMS，再解INFO；INFO0不單獨證明成功。

來源：NVM Command Set 1.3 §4.1.1 · Base 2.4 §5.2.11 · Base 2.4 §5.2.13.1.14.2.7 · Base 2.4 §5.2.13.1.14.2.8

來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.1, Figure 91, 文件頁 63, PDF 頁 63

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.11, Figure 195, 文件頁 208-209, PDF 頁 234-235

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.7, Figure 248, 文件頁 260, PDF 頁 286

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.8, Figure 249, 文件頁 260-261, PDF 頁 286-287

NVM Figure 91 · Format NVM – Command Dword 10 – NVM Command Set Specific Fields

一句話重點

NVM91-1NVM補定Format命令的bits8:4，沒有改變Base的SES和格式編號位置。

來源：NVM Command Set 1.3 §4.1.1

來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.1, Figure 91, 文件頁 63, PDF 頁 63

用例子讀懂

NVM91-2MSET1、PI1、PIL0組成低位的30h，再加format index2得到32h；這是Format CDW10，不是事件FLBAS32h的意思。

欄位、條件與相關細節：開始參數與完成結果分別解讀 →

從Create／Identify來源對到48-byte事件

11.22.Figure247給位置與來源，NVM112補byte32／33；NVM123與134只取本事件用到的欄位，不展開整份長結構。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
NMCDW10 ED3:0；SEL bits3:0	0Create、1Delete、2Restore Default Namespace Configuration，3～15保留；bits31:4保留。	Restore有其命令碼，但本事件表的Create／Delete取值規則不應擅自擴寫成Restore後所有欄位的快照。
NSZE ED15:8；NCAP31:24	Create取主機值；單一Delete取該namespace值；Delete All保留。皆以logical blocks計，NCAP是可配置上限，NSZE是可定址範圍大小。ED7:4、23:16保留。	NSZE1000與NCAP800不是1000bytes與800bytes。
FLBAS ED32 ← NVM來源byte26	bit7保留；bits6:5為FIDXU，bits3:0為FIDXL。超過16種格式時index=(FIDXU<<4)\|FIDXL；≤16時應忽略FIDXU。bit4 MTELBA選延伸LBA或分開buffer，無metadata時不適用。	12h是index2、metadata延伸傳輸，不是18-byte LBA。
DPS ED33 ← NVM來源byte29	bits2:0 PIT：0未啟用、1／2／3各PI類型、4～7保留；bit3 PIP選metadata前／後，NVM1.3要求0放尾端；bits7:4保留。	01h啟用Type1並放尾端。這裡的PIT不是事件header的Port Identifier Type。
兩欄取值時機	FLBAS／DPS在Create取主機指定值、單一Delete取Identify值、Delete All保留；不拿目前新建同號namespace的Identify代替歷史值。	原NSID7刪除後再次分配7，今天的格式可能與舊事件不同。
NMIC ED34；ED35保留	低bit表示是否可共享於多控制器；取Create輸入或單一Delete的namespace值，Delete All保留。	共享能力不等於目前有幾個控制器附接。
ANAGRPID ED39:36	Create主機有指定取指定值，否則取控制器實際選擇；單一Delete取當時值，Delete All保留；不支援時0。	ID是存取狀態群組識別，並非容量或namespace計數。
NVMSETID ED41:40；ENDGID43:42	Create取主機指定，單一Delete取namespace值，Delete All保留；Create來源的0可表示由控制器決定。	事件保留的輸入0不等於裝置內必然有一個編號0的實體。
NSID ED47:44	Create為成功分配的新ID；單一Delete為被刪除ID；Delete All為FFFFFFFFh。	成功Create記錄物件建立，不證明主機已完成Attachment。
來源位置與未保存內容	NVM來源NSZE7:0、NCAP15:8、NMIC30、ANAGRPID95:92、NVMSETID101:100、ENDGID103:102。其他Create專屬欄位不在此48-byte事件格式中。	只對照表列欄位，不把來源buffer的所有保留間隔照搬進事件。

ANAGRPID: ANA Group Identifier，namespace 所屬 Asymmetric Namespace Access group 的 identifier；create 值 0 讓 controller 選擇。
NVMSETID: NVM Set Identifier，指定建立 namespace 時要從哪個 NVM Set 配置容量。
NMIC: Namespace Multi-path I/O and Namespace Sharing Capabilities，create 時宣告 namespace sharing／multipath 屬性的欄位。

來源：NVM Command Set 1.3 §4.1.4.4 · NVM Command Set 1.3 §4.1.5.1 · NVM Command Set 1.3 §4.1.6 · Base 2.4 §5.2.13.1.14.2.6 · Base 2.4 §5.2.25

Base195-1Format index被拆成高低欄位，SES則另選安全清除動作。

來源：Base 2.4 §5.2.11

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.11, Figure 195, 文件頁 208-209, PDF 頁 234-235

用例子讀懂

Base195-2LBAFU1、LBAFL2在extension有效時選index18；SES1另表示User Data Erase。不能把bits13:9合成一個更大的格式號。

欄位、條件與相關細節：開始參數與完成結果分別解讀 →

Base Figure 247 · Change Namespace Event Data Format (Event Type 06h)

一句話重點

Base247-1先看NMCDW10的動作與NSID，才能決定容量和格式欄位是否有效。

來源：Base 2.4 §5.2.13.1.14.2.6

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.6, Figure 247, 文件頁 258-259, PDF 頁 284-285

Base446-2NMCDW10=00000001h表示Delete；要刪一個或全部還得讀NSID。數字1不代表namespace1。

圖表組 07 · 把清除開始、完成與媒體驗證分開 · 6 張圖表

11.23.Figures250／251連到Sanitize參數與狀態；ET0E本身沒有另畫內容表。

回到本節的解釋與範例

讀出清除的對象、要求與結果

11.24.先以subsystem目標解Figures451／452的啟動參數，namespace目標另用Figure454；Figure312取SPROG／SSTAT，供250／251事件解碼。ET0E無ED的規則見共同外框與事件類型組。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
Start ED：SANICAP3:0、SCDW10 7:4、SCDW11 11:8、NSID15:12	前三欄保存當時控制器能力與原始命令Dwords；NSID為單一目標或FFFFFFFFh整個subsystem。	ET09新版ED16 bytes；讀舊ETR前不能先假設尾端有NSID。
SCDW10 SANACT2:0、AUSE3	SANACT1退出failure、2block erase、3overwrite、4crypto erase、5退出verification；0／6／7保留。AUSE1選unrestricted處理，0restricted；非啟動動作忽略。	開始事件是進入處理狀態；不把所有SANACT代碼都當成會觸發start。
SCDW10 OWPASS7:4、OIPBP8、SCDW11 OVRPAT31:0	overwrite次數1～15直接表示、0表示16；OIPBP1各次間反相pattern，OVRPAT為32-bit pattern。非overwrite忽略這些欄。	OWPASS2且patternAAAAAAAAh的反相值為55555555h。
SCDW10 NDAS9、EMVS10、PREQ11	NDAS要求清除後不deallocate，仍受SANICAP.NDI與回應模式影響；EMVS要求成功後進verification；PREQ要求Purge結果，須支援SPRRS。bits31:12保留。	NDAS1不是無條件保留allocation；EMVS1也不是已進驗證的證明。
Complete ED：SPROG1:0、SSTAT3:2、CINFO5:4、NSID11:8	CINFO為廠商結果補充，bytes7:6保留。SPROG進度刻度n/65536，Media Verification或非SOS2時為FFFFh。	8000h在可用的處理進度情境是50%；FFFFh須先讀SOS與狀態。
SSTAT SOS2:0、OPC7:3	SOS0未曾sanitize、1成功、2處理中含verification／post-verification、3失敗、4成功但未預期deallocate，5～7保留。OPC是完成的overwrite輪次；非overwrite或namespace目標為0。	OPC2表示已完成2輪，不是要求做2輪；要求看OWPASS。
SSTAT GDE8、MVCNCLD9、NDE10	GDE描述自出廠或最近成功subsystem sanitize後未再寫user data且未啟用PMR；MVCNCLD描述EMVS驗證因配置變更或相關reset被取消；NDE在namespace目標描述自建立或最近成功涵蓋該namespace清除後未再寫user data。	GDE／NDE是不同範圍，不能拿某namespace的NDE1推論整個subsystem無資料。
SSTAT PRGD11、15:12保留	只有SPRRS受支援、PREQ1且SOS1的成功條件下才依Purge結果回報；其餘為0。	PRGD0不能脫離能力、請求與SOS就判斷作業失敗。

PMR: Persistent Memory Region，由 controller 暴露、具有持久性語意的記憶體區域。

Base452-1SCDW11保存overwrite pattern，不是byte長度或完成碼。

來源：Base 2.4 §5.2.26

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.26, Figure 452, 文件頁 451, PDF 頁 477

用例子讀懂

Base452-2SCDW11=AAAAAAAAh、OIPBP1表示overwrite輪次間反相pattern；若動作不是overwrite，不能把這個數字解成有用的清除參數。

欄位、條件與相關細節：讀出清除的對象、要求與結果 →

同樣的SCDW10名稱，不同目標要換格式

11.25.Figure250同時記錄namespace與subsystem清除。遇到namespace目標，要補用Figure454解原始命令，不把Figure451的overwrite欄位套過來。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
SANACT2:0	1退出failure，4啟動namespace crypto erase，5退出verification；其他值保留。	不把值2／3解成namespace block erase／overwrite。
AUSE3；PREQ4；EMVS10	AUSE1unrestricted、0restricted；PREQ要求Purge、須SPRRS支援；EMVS1要求成功後進驗證。非啟動動作忽略AUSE／EMVS。	41Ch=400h+10h+8h+4h，與一般Sanitize bit11的PREQ不同。
保留欄位	bits9:5、31:11保留；此命令沒有overwrite pattern用途的CDW11。	不從保留的SCDW11數值推論曾執行overwrite。

來源：Base 2.4 §5.2.27

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.27, Figure 454, 文件頁 453, PDF 頁 479

Base Figure 454 · Sanitize Namespace – Command Dword 10

一句話重點

Base454-1Namespace Sanitize的PREQ在bit4，不在一般Sanitize的bit11。

來源：Base 2.4 §5.2.27

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.27, Figure 454, 文件頁 453, PDF 頁 479

用例子讀懂

Base454-2namespace目標的SCDW10=0000041Ch：SANACT4、AUSE1、PREQ1、EMVS1；bit4不是要求overwrite1次。這是依命令種類選格式的必要差別。

欄位、條件與相關細節：同樣的SCDW10名稱，不同目標要換格式 →

圖表組 08 · 先選硬體錯誤代碼，再選附加資料格式 · 9 張圖表

11.26.Figure242是共同外框，243選子類，244～246是三種不同的附加資料。

回到本節的解釋與範例

保存的CQE怎麼接到事件結果

11.27.Figures97～99只取PCIe共同CQE；Figure101的bit號相對CQE DW3。Format INFO則保存高半部，包括Status與可能的Phase。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
CQE bytes7:0：DW0／DW1	兩者依原命令定義，未使用者保留。	Set Feature事件可只保留DW0，硬體子類0Ah則保存整份CQE。
DW2：SQID31:16、SQHD15:0	對應CQE bytes11:10與9:8，識別SQ與建立completion時的SQ head。	它們不是NSID或PEL offset。
DW3：CID15:0、P16、STATUS31:17	CID配SQID辨識命令；P為Phase Tag；Status不包含P。	Phase1不等於命令成功。
DW3：SC24:17、SCT27:25	SC是類型內的碼，SCT選類型；SCT0／SC0表示成功。	解Format INFO時位址已右移16bits，所以SC在INFO8:1、SCT在11:9。
DW3 DNR31、M30、CRD29:28	DNR1相同命令重送預期仍失敗；M1有額外Error Information；CRD只在DNR0且ACRE1有意義，0不延遲，1～3選CRDT1～3等待值，其餘情況保留。	CRD2是選第2個等待參數，不是固定2秒；DNR0只說可能成功。

SQID: Submission Queue Identifier，辨識 command 所屬 SQ 的數值。
CID: Command Identifier，與 SQ identifier 合用以辨識 outstanding command。
CRD: Command Retry Delay，status 中選擇 controller 建議重試延遲值的欄位。
SQ: Submission Queue，主機放入命令的提交佇列。

來源：Base 2.4 §4.2.3

來源：NVME-BASE-2.4, Rev. 2.4, §4.2.3, Figure 101, 文件頁 145-146, PDF 頁 171-172

用例子讀懂

Base101-2SCT2／SC80h與SCT0／SC80h不能只因SC相同就翻成同一錯誤；DNR0也不是重試保證成功。

欄位、條件與相關細節：保存的CQE怎麼接到事件結果 →

先用子類找到正確的證據格式

11.28.Figure242：NSHEEC bytes1:0，bytes3:2保留，AHEI從4起。ETR2中未能提供的欄位依規則為0，除非該欄另有指定。子類支援由廠商決定。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
01h／02h／03h：PCIe錯誤	分別是correctable、uncorrectable non-fatal、uncorrectable fatal；AHEI用Figure245。	先分correctable與uncorrectable，才能選狀態／mask register。
04h：PCIe link status change	因嘗試修正不可靠link而改變；AHEI是PCIe Link Status register快照，不是Figure245整份結構。	這個數值保存連線狀態，不能解成UPL計數或套AER各slot。
05h：PCIe link not active；09h：fatal status	05是非預期離開Data Link Active；09是CSTS.CFS設1。兩者沒有AHEI。	ED只含4-byte共同前綴也可以是完整事件。
06h：Critical Warning	AHEI為SMART byte0的Critical Warning格式，在事件發生時的值。	值04h表示可靠度警告bit2，不是錯誤子類04h。
07h：Endurance Group warning	AHEI byte0為該Group警告、byte1保留、bytes3:2為Group ID；值反映加入log時狀態。	Group ID3不是TNEV3；不同Group可能有不同警告。
08h：Unexpected Power Loss	AHEI依Figure244。	用128-bit累計UPL與特殊情境位元解讀，不按PCIe表。
0Ah：Media/Data Integrity	AHEI為完整CQE；Access Denied SC86h與Deallocated/Unwritten SC87h不在此觸發類型。	CQE帶命令識別與狀態，不是出錯LBA清單。
0Bh：Controller Ready Timeout Exceeded	AHEI依Figure246。00h及0Ch～FFFFh未定義的碼不按已知格式解讀。	先檢查外框長度再交給對應表，未知子類仍保留原始bytes。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 242, 文件頁 254, PDF 頁 280

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 243, 文件頁 254-255, PDF 頁 280-281

Base Figure 242 · NVM Subsystem Hardware Error Event Format (Event Type 05h)

一句話重點

Base242-1ET05的ED先有子類代碼，再有由子類選定的AHEI。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 242, 文件頁 254, PDF 頁 280

用例子讀懂

Base242-2ED前2 bytes=0008h、後面AHEI17 bytes：可按unexpected-power-loss結構解。若前2 bytes改為000Bh，同一批17 bytes就不能仍照電源事件讀。

欄位、條件與相關細節：先用子類找到正確的證據格式 →

Base Figure 243 · NVM Subsystem Hardware Error Event Codes

一句話重點

Base243-1子類表是格式分派表，不是錯誤嚴重程度由小排到大。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 243, 文件頁 254-255, PDF 頁 280-281

用例子讀懂

Base243-206h用Critical Warning，0Ah用完整CQE，0Bh用ready-timeout狀態；數字0Bh比06h大，不代表前者一定比較嚴重。

欄位、條件與相關細節：先用子類找到正確的證據格式 →

累計次數與特定情境分開

11.29.Figure244的offset相對AHEI起點，不是ED或事件起點。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
UPL bytes15:0	128-bit累計非預期掉電次數，值為事件當時所記。	不要只讀低4 bytes，或把它當掉電發生的Timestamp。
UPLI byte16：UPLOA bit0	僅在SHST01／10且主電源掉落、媒體因Ignore Shutdown1的帶外Admin操作仍未shutdown時設1。bits7:1保留。	SHST10不是在所有情況都保證媒體當下已不用電；此bit描述明確的例外條件。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 244, 文件頁 256, PDF 頁 282

Base Figure 244 · Additional Hardware Error Information for Unexpected Power Loss Errors

一句話重點

Base244-1UPLOA只標一種帶外管理造成的特殊掉電條件，不是所有非預期掉電的總開關。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 244, 文件頁 256, PDF 頁 282

用例子讀懂

Base244-2UPL=12、UPLOA=0：已記錄到累計第12次非預期掉電，只是未標示該特殊情境。不能因UPLOA0把這次事件改判正常shutdown。

欄位、條件與相關細節：累計次數與特定情境分開 →

把快照槽位與原始PCIe register分開

11.30.此處AER指PCIe Advanced Error Reporting，不是NVMe的Asynchronous Event Request。Figure245定義保存位置；原PCIe register的逐bit意義不是由這張NVMe表定義。

NVMe: Non-Volatile Memory Express，主機與非揮發性記憶體子系統之間的介面規範家族。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
PCIEDSR1:0；PCIEAS2 bit0 PCIEAERS	前者保存Device Status；後者1表示報AER，0表示AER區省略或清零。PCIEAS bits7:1及bytes15:3保留。	事件存在且AERS0仍可有Device Status，不能推成無錯誤。
PCIEAES31:16；PCIEAEM47:32	各佔16-byte保存槽位，分別為所選correctable／uncorrectable的Error Status與Mask register內容。	slot寬度不表示原生register就是128bits；status和mask不能互換。
PCIEAHLR63:48；PCIEATPLR79:64	分別為Header Log與TLP Prefix Log register快照，存在與內容依支援。	沒有實作的prefix資料不能解成16-byte全零的有效封包。
AHEI解讀邊界	先確定子類和PCIEAERS，再保留各register原始值；本NVMe外框未提供的PCIe bit碼不能自行命名為某個link速率或故障原因。	能確定「哪個register在何時被保存」，不憑這張外框表捏造逐bit含義。

TLP: Transaction Layer Packet，PCIe transaction layer 傳送的 packet。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 245, 文件頁 256-257, PDF 頁 282-283

Base Figure 245 · Additional Hardware Error Information for correctable and uncorrectable PCIe

一句話重點

Base245-1PCIEAERS決定AER資訊能否讀；error code再決定correctable或uncorrectable的register。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 245, 文件頁 256-257, PDF 頁 282-283

用例子讀懂

Base245-2NSHEEC01h且PCIEAERS1時讀correctable狀態與mask；NSHEEC03h改用uncorrectable。PCIEAERS0時後面的AER區可以省略或清零，不應把零報為「PCIe沒有錯」。

欄位、條件與相關細節：把快照槽位與原始PCIe register分開 →

同一啟用時點，兩種等待尺度

11.31.AHEI byte0為CST；bytes3:1保留。計時從CC.EN 0→1啟用控制器開始，CRTO是Controller Ready Timeouts。

CRTO: Controller Ready Timeouts，回報特定 ready mode 所需等待時間的 property。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
CST bit3：CNR	控制器未能在模式所選時間內無錯處理至少一筆命令；CRIME0用CRWMT，1用CRIMT。	CNR1不是說每個namespace都一定壞掉。
bit2 ACMNR；bit1 NNR	ACMNR表示至少一筆Admin命令所需媒體未在CRWMT內就緒；NNR表示至少一個附接namespace未在CRWMT內就緒。	兩位可以獨立觀察，Admin所需媒體與namespace範圍不同。
bit0 CRIME；bits7:4保留	保存事件時CC.CRIME：0連同media就緒模式，1media獨立模式。	CRIME是模式，不是另一個錯誤；CST1只設模式位。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 246, 文件頁 258, PDF 頁 284

Base Figure 246 · Additional Hardware Error Information for Controller Ready Timeout Exceeded errors

一句話重點

Base246-1CRIME保存當時ready模式，其他位元描述各範圍是否超過等待限制。

來源：Base 2.4 §5.2.13.1.14.2.5

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.5, Figure 246, 文件頁 258, PDF 頁 284

用例子讀懂

Base246-2CST=0Bh：CNR1、ACMNR0、NNR1、CRIME1。控制器等待使用CRIMT，namespace等待仍用CRWMT；不能因同一byte就認為兩者共用相同timeout。

欄位、條件與相關細節：同一啟用時點，兩種等待尺度 →

圖表組 09 · 設定事件如何保留命令與資料 · 3 張圖表

11.32.Figure252先判斷是否記錄，253再解資料位置；256是另一種專屬事件格式。

回到本節的解釋與範例

以控制器類型和FID讀記錄政策

11.33.本表只呈現I/O與Admin兩欄。O選用、P禁止、NR不建議；M代表必備但這些列沒有M。成功且改值、又支援該Feature記錄時須記；同值成功時可記。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
I/O O；Admin P	01h Arbitration、06h Volatile Write Cache、07h Number of Queues、13h Predictable Latency Mode Config、19h I/O Command Set Profile、1Ah Spinup Control、1Dh Flexible Data Placement、1Eh其Events、82h Reservation Notification Mask、83h Reservation Persistence。	同一FID不能略過控制器類型直接說一定可記。
I/O P；Admin O	14h Predictable Latency Mode Window。	P限制本事件種類的記錄，不是要求把已存在記錄刪除。
兩欄P；兩欄NR	0Eh Timestamp為P。02h Power Management、0Bh Asynchronous Event Configuration、80h Software Progress Marker為NR。	NR比禁止寬，不可改寫成must not。
兩欄O：中斷、熱管理與記憶體	04h Temperature Threshold、08h Interrupt Coalescing、09h Interrupt Vector Configuration、0Ch Autonomous Power State Transition、0Dh Host Memory Buffer、0Fh Keep Alive Timer、10h Host Controlled Thermal Management、11h Non-Operational Power State Config、12h Read Recovery Level Config。	O不是說每台裝置都會保留這類歷史。
兩欄O：設定與電源	16h Host Behavior、17h Sanitize Config、18h Endurance Group Event Config、1Bh Power Loss Signaling、1Fh Namespace Admin Label、21h Controller Data Queue、22h CDP、23h Power Limit、24h Power Threshold、25h Power Measurement、26h Voltage Threshold、27h Voltage Measurement。	這裡只分類記錄政策，各Feature的參數不能共用一套CDW11格式。
兩欄O：管理資料與保護	78h Embedded Management Controller Address、79h Host Management Agent Address、7Dh Enhanced Controller Metadata、7Eh Controller Metadata、7Fh Namespace Metadata、81h Host Identifier、84h Namespace Write Protection Config、85h Boot Partition Write Protection Config。	Metadata這幾個FID是管理屬性，不是FLBAS控制的每LBA metadata。
Command Set自訂列	03h、05h、0Ah、15h、1Ch、20h、28h：Base把政策交給對應command set。	不要把空白／引用另一份表猜成O或P；本篇NVM§4.1.4.4沒有重定義這些列。

來源：Base 2.4 §5.2.13.1.14.2.11

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, Figure 252, 文件頁 262-263, PDF 頁 288-289

Base Figure 252 · Feature Persistent Event Logging Requirements

一句話重點

Base252-1每一格說的是Feature事件的記錄政策，不是在宣告能否使用Feature。

來源：Base 2.4 §5.2.13.1.14.2.11

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, Figure 252, 文件頁 262-263, PDF 頁 288-289

用例子讀懂

Base252-2FID14h在I/O欄P、Admin欄O；選錯控制器類型就會把選用記錄讀成禁止。Timestamp0Eh的P另有ET03處理，不能推論不支援時間設定。

欄位、條件與相關細節：以控制器類型和FID讀記錄政策 →

沿長度找到命令、buffer與完成值

11.34.所有offset相對ED；SFEL本身先佔4 bytes。不要把這裡的直接計數DWC套用Get Log NUMD的0-based規則。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
SFEL3:0：DWC2:0	有效1～6，0／7保留；保存CDW10起連續Dwords，直到最高非保留CDW，中間保留CDW也算進去。	DWC3表示CDW10、11、12，不是CDW10～13。
SFEL：LCCDW0 bit3；MBC31:16	bit3=1表示保存完成DW0；MBC為buffer bytes數，0沒有buffer；bits15:4保留。	0008000Bh的8是8 bytes，不是8Dwords。
CDWS起4；MBUF起4+4DWC	CDWS長4DWC；MBUF長MBC。	DWC3時MBUF從16開始；MBC0時後續欄位緊接16。
CCDW0起4+4DWC+MBC	只在LCCDW01時存在，長4；ED總長4+4DWC+MBC+4×LCCDW0。	它不是CQE的Status或全部16-byte CQE。

來源：Base 2.4 §5.2.13.1.14.2.11

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, Figure 253, 文件頁 264, PDF 頁 290

Base Figure 253 · Set Feature Event Data Format

一句話重點

Base253-1DWC算Dwords、MBC算bytes、LCCDW0只決定是否再有4 bytes。

來源：Base 2.4 §5.2.13.1.14.2.11

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, Figure 253, 文件頁 264, PDF 頁 290

用例子讀懂

Base253-2SFEL0008000Bh：DWC3、MBC8、LCCDW01。ED是28 bytes，最後4 bytes在offset24；不是把DWC3先加1再乘4。

欄位、條件與相關細節：沿長度找到命令、buffer與完成值 →

把請求、錯誤與personality專屬資料分開

11.35.Figure256是ET0F獨立格式，不套Set Feature的SFEL。Manufacturing Default要求只產生一筆相關事件。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
PS0：CDPRFS bit1、CDPCE bit0	bit1為要求的freeze狀態，bit0表示personality change error；bits7:2保留。	03h不是「兩種personality已成功凍結」。
PERID1；bytes11:2保留	PERID選personality；設定、更改freeze狀態及安全條件自動freeze可觸發此事件。	PERID是識別值，不是數量。
PED由12起，長EL−VSIL−12	保存該personality的Set Features資料buffer，具體結構依PERID而異；本共同表不定義所有personality的內部bits。	可以定位保存資料，但不能拿另一PERID的payload欄位照套。

來源：Base 2.4 §5.2.13.1.14.2.15

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.15, Figure 256, 文件頁 267, PDF 頁 293

Base Figure 256 · CDP Change Event Data Format (Event Type 0Fh)

一句話重點

Base256-1PS的requested freeze與change error要合讀，PED再依PERID解。

來源：Base 2.4 §5.2.13.1.14.2.15

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.15, Figure 256, 文件頁 267, PDF 頁 293

用例子讀懂

Base256-2PS=03h表示要求freeze且變更有錯誤；不能因bit1=1就報告已成功freeze。PED從12開始，不是把保留的bytes11:2當設定值。

欄位、條件與相關細節：把請求、錯誤與personality專屬資料分開 →

圖表組 10 · 識別值映射與廠商擴充如何讀到正確邊界 · 4 張圖表

11.36.Figure257按OTYP選識別值；258～260由清單走到描述子，再選型別。

回到本節的解釋與範例

只讀實體變更紀錄中的映射

11.37.ET10的ED16 bytes。此處只教物件、動作與ID關係，不展開建立或傳輸流程。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
ESUBID1:0；OTYP2	ESUBID識別被改變的exported subsystem；OTYP0建立、1刪除subsystem；2加namespace、3刪namespace；4加controller、5刪controller；6加port、7刪port；8允許主機清單改變、9限制存取改變，其他保留。	OTYP4時EEID5是一個controller ID，不能仍稱namespace5。
bytes7:3保留；EEID11:8	namespace動作2／3用32-bit ID；0／1／8／9的低16bits是exported subsystem ID，4／5是controller ID，6／7是port ID，各自高16bits保留。	namespace ID可以大於65535，不該把EEID一律截成16-bit。
UEID15:12	0／1／8／9動作清0；2／3底層namespace32-bit；4／5底層controller低16；6／7底層port低16，其餘高位保留。	建立subsystem時UEID0不是底層namespace0，而是該動作規定的零值。

來源：Base 2.4 §5.2.13.1.14.2.16

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.16, Figure 257, 文件頁 267-268, PDF 頁 293-294

Base Figure 257 · Exported NVM Subsystem Change Event Data Format (Event Type 10h)

一句話重點

Base257-1EEID與UEID分別是呈現出去與底層的識別值，寬度還要看OTYP。

來源：Base 2.4 §5.2.13.1.14.2.16

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.16, Figure 257, 文件頁 267-268, PDF 頁 293-294

用例子讀懂

Base257-2ESUBID2、OTYP2、EEID5、UEID42表示新增Exported namespace5對應Underlying namespace42；兩個不同數字不是錯誤，而是映射兩端。

欄位、條件與相關細節：只讀實體變更紀錄中的映射 →

描述子串列、前綴與型別逐層解

11.38.Figure258是串列，259是一筆，260選資料型別。UUID Index選擇相應的vendor事件，廠商自行定義的事件仍可回報；不得把索引當全域事件序號。

欄位或表中分類	位置、數值與成立條件	帶入例子後怎麼讀
VSEC1:0；VSEDT2；UIDX3	VSEC為同類vendor事件一致使用的碼；VSEDT選型別；UIDX為事件發生時使用的UUID Index。	沒有vendor碼表，不能把VSEC0010h直接翻成過熱。
VSEDL5:4；VSED從6起	VSEDL只計資料，下一描述子前進6+VSEDL；整個串列不得超過ED邊界。	名稱TEMP含零結尾5bytes，描述子11bytes。
VSEDT1：Event Name；2：ASCII String	皆以零字元結尾；有Event Name時必須第一描述子，名稱與相應事件碼保持一致。	字串長度包含終止零，不是只計可見字元。
VSEDT3：Binary；4：Signed Integer	binary的byte order由廠商定義；integer為64-bit有號二補數。0與5～FFh保留。	型別4應是8-byte內容，不能把任意長度資料截短硬解。
與VSI、TCG的界線	這一組只解ETDE的ED；共同外框VSI是另一段。ETDF的ETR／ED由TCG保留定義，不沿用這份描述子格式。	外框可保留並跳過未知內容，不代表已知其中安全事件的語意。

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.17, Figure 260, 文件頁 269-270, PDF 頁 295-296

用例子讀懂

Base260-28個FFh在VSEDT4是有號64-bit二補數−1；在VSEDT3只是廠商binary資料，不能擅自選有號整數或byte order。

欄位、條件與相關細節：描述子串列、前綴與型別逐層解 →

學完後想一想

1. ACT3成功回RCE=0，要再送ACT1才能讀事件嗎？

12.01.不需要。RCE0表示命令處理前沒有context，ACT3已建立並回header；接續用ACT0。這時再送ACT1，反而因已有context而得到Command Sequence Error。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-246,251, PDF 頁 271-272,277

2. EHL21、VSIL4、EL20時，事件是44還是48 bytes？

12.02.44。EHL+3是24-byte header；EL20已含4-byte VSI，ED只剩16。48把VSI算了兩次，會錯過下一筆的開頭。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 247-251, PDF 頁 273-277

3. PEL的Telemetry header寫Data Area3有9個blocks，這筆事件含那些資料嗎？

12.03.不含。ET0C只複製前512 bytes header，提供當時的邊界、原因和generation等資料；不能當成完整Telemetry內容，也不保證現在還能取得相同版本。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.1; 5.2.13.1.14.2.12; 5.2.13.1.14.2.13, 文件頁 252,264-266, PDF 頁 278,290-292

4. 事件byte32=12h就能說這份namespace每個LBA有18 bytes嗎？

12.04.不能。有效FLBAS裡12h代表format index2與延伸LBA metadata，不是大小18。還要先確認操作不是Delete All；實際資料與metadata大小來自所選格式定義。

來源

來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.4, 文件頁 76-77, PDF 頁 76-77

來源：NVME-NVM-CS-1.3, Rev. 1.3, §4.1.5.1; 4.1.6, 文件頁 85-87,112-113, PDF 頁 85-87,112-113

5. Sanitize completion事件的SPROG=FFFFh，是否能證明已成功清除？

12.05.不能。先讀SOS；例如SOS3就是失敗。FFFFh也用在非處理狀態與Media Verification，這不是一個可獨立判斷成功的百分比。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.9; 5.2.13.1.14.2.10; 5.2.13.1.14.2.14, 文件頁 261-262,266, PDF 頁 287-288,292

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.38, 文件頁 314-316, PDF 頁 340-342

6. 找不到某次設定事件，就能說主機沒改過設定嗎？

12.06.不能。先看該Feature的記錄政策與支援；有些禁止用ET0B記錄，有些是選用或不建議。再考慮容量淘汰、頻率抑制，以及目前context是否早於那次變更。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14.2.11, 文件頁 262-264, PDF 頁 288-290

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 244-245, PDF 頁 270-271

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.14, 文件頁 245-246,251, PDF 頁 271-272,277