NVMe Base 2.4: Device Self-test: execution, progress, and results

00.01.Device Self-test lets a controller run internal tests in the background. Distinguish accepting a request, running a test, and recording its result: successful command completion does not mean the device has passed the test.

controller: Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.

The main ideas

Choose the test and target

01-01Check support, choose the test and namespaces, and distinguish accepting the request from running the background test.

Follow the running operation

02-01Use the current operation and completion percentage to follow progress, accounting for commands, resets, and abort requests.

Interpret the recorded result

03-01Read the result after the test stops. Check field validity before interpreting failure locations and associated information.

Connecting the main ideas

00.02.Check supported tests, select the test and namespaces, submit the command, observe the current operation and progress, and finally read historical results and validity indicators. Get Log Page can answer both progress and outcome questions at different times, using different fields.

01 Starting and running Device Self-test

01.01.Self-test is not a synchronous diagnostic RPC. The host first uses OACS.DSTS, DSTO.SDSO, and EDSTT to establish support, concurrency scope, and timing, then constructs the command from NSID and STC. When the Admin CQE returns, the background operation has only entered the lifecycle observed through LID 06h.

OACS.DSTS: The Device Self-test Supported bit in Optional Admin Command Support, gating availability of the command.
LID 06h: Identifier 06h for the Device Self-test Log Page, containing current operation state and twenty historical results.
Admin: Administrative, the control path used to create, configure, query, or manage controllers and queues.
EDSTT: Extended Device Self-test Time, the nominal extended-test duration in minutes at power state 0.
DSTO: Device Self-test Options, the Identify Controller field reporting refresh and concurrency options.
Host: The system running the operating system and issuing NVMe commands.
NSID: Namespace Identifier, a controller-visible numeric handle for a namespace; the identifier is not the namespace object itself.
SDSO: Single Device Self-test Operation, the bit selecting one subsystem-wide operation or one per controller.
CQE: Completion Queue Entry, one completion-result structure in a CQ.
LID: Log Page Identifier: selects the type of log page to read.
STC: Self-test Code is the Device Self-test CDW10 action nibble; STC in a result entry instead means Status Code and is gated by SCVLD.

01.02.Before starting Device Self-test, read Identify Controller. OACS.DSTS gates command support, EDSTT gives the nominal extended-operation time in minutes at power state 0, and DSTO.SDSO selects one subsystem-wide operation versus one operation per controller. These fields answer different questions.

Sources: Base 2.4 §5.2.14.2.1, 8.1.8

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, 8.1.8, printed pages 352-358, 614, PDF pages 378-384, 640

Starting and running Device Self-test
Test target or control	Scope or action	Execution and result rules
NSID=0	Controller only	No namespace media
Active NSID	One namespace	Invalid and inactive status differ
NSID=FFFFFFFFh	All attached/accessible namespaces	Set is captured at start
STC=Fh	Abort current operation	Success does not prove one existed

namespace: Namespace, a formatted quantity of non-volatile memory accessed by a host through a controller.

02 Current progress and history in LID 06h

02.01.DSTOS/DSTCS in the header answer what is running now, while RDS1 through RDS20 answer how earlier operations ended. Each result then separates operation code, result reason, segment, validity bitmap, and diagnostic payload. The NVM Command Set gives FLBA an LBA meaning only when FVLD is one.

DSTCS: Device Self-test Completion Status, the LID 06h completion percentage from 0 through 100.
DSTOS: Device Self-test Operation Status, the LID 06h nibble identifying the current operation.
FLBA: Failing LBA, defined by the NVM Command Set as one logical block address that caused self-test failure.
FVLD: Failing LBA Valid, the validity bit determining whether FLBA may be interpreted.
NVM: Non-Volatile Memory, memory that retains data without power.

02.02.The minimum Get Log Page slice for LID 06h uses LID 06h, LSP 0, RAE selected by event policy, NUMD for 564 bytes, LPOL/LPOU 0, OT 0, CSI 0, and UIDX 0. 564 bytes are 141 dwords, so zero-based NUMD is 140 or 008Ch; with RAE 0, CDW10 is 008C0006h.

zero-based: zero-based: numbering starts at zero, so raw=3 can mean the fourth item or four units; the field definition still decides which.
LPOL: Log Page Offset Lower, the low 32 bits of the Get Log Page byte offset.
LPOU: Log Page Offset Upper, the high 32 bits of the Get Log Page byte offset.
NUMD: Number of Dwords, a zero-based transfer-dword count; actual bytes = (NUMD + 1) × 4.
UIDX: UUID Index, an index into the UUID List; zero indicates that no UUID is specified.
CSI: I/O Command Set Identifier: selects an I/O command set; NVM uses 00h.
LSP: Log Specific Field, a command selector whose meaning is defined by the selected log page.
RAE: Retain Asynchronous Event, the Get Log Page selector controlling retention of a related asynchronous event.

Sources: Base 2.4 §5.2.13

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13, printed pages 213-216, PDF pages 239-242

Current progress and history in LID 06h
Progress or history field	Information described	When the field is valid
DSTOS/DSTCS	Current state/progress	Ignore percentage when DSTOS=0
DSTR=7h + SEGN	Known first failed segment	Ignore SEGN for other DSTR
FVLD + FLBA	One failing LBA	Not a list of every failed LBA
POH + STCT/STC	Failure context	Validity bits still apply

DSTR: Device Self-test Result, the result-entry nibble identifying success, abort, or segment failure.
SEGN: Segment Number, identifying the first failed diagnostic segment only when DSTR is 7h.
POH: Power On Hours, accumulated power-on hours when a self-test result is created, excluding specified low-power time.

Where to continue in the specification

03.01.Use the flow above to frame the problem, then open the corresponding sections for fields and full conditions. The Chinese tutorial also explains every in-scope figure with its takeaway, example, and details.

Concept to explain	Specification sections
Starting and running Device Self-test	Base 2.4 §5.2.14.2.1, 8.1.8 · Base 2.4 §5.2.6
Current progress and history in LID 06h	Base 2.4 §5.2.13 · Base 2.4 §5.2.13.1.7 · NVM 1.3 §4.1.4.3

Open the complete Chinese tutorial and figure explanations →

Check your understanding

1. After a successful Device Self-test start command, how can ongoing execution be determined?

04.01.The start completion is not the test’s final outcome. The Device Self-test log reports current operation and completion percentage for ongoing work, while result records describe finished tests.

Sources

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.6, printed pages 201, PDF pages 227

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.7, printed pages 229-230, PDF pages 255-256

2. Can a plausible FLBA in a self-test result always be treated as the failure location?

04.02.Check its validity bit first; the value cannot be interpreted if it is not marked valid. Even when valid, it may identify only one of several failed logical blocks, rather than the complete range.

Sources

Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.7, printed pages 231-232, PDF pages 257-258

Source: NVME-NVM-CS-1.3, Rev. 1.3, §4.1.4.3, printed pages 76, PDF pages 76

Jia-Chang

Human

Comments

Write a comment ...