NVMe Self-Study Bank: Device self-test

NVMe · Q1–328

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

Q149–Q156

Device self-test

Establish supported tests, then distinguish progress, final results and valid failure details.

Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.

SCT
Status Code Type

Start, progress and result are distinct

Successful initiation does not mean a passed test.

ObservationInterfaceUse
CapabilityOACS, DSTOSupport and concurrency
ProgressCurrent operation and percentageTrack current work
ResultNewest test/result codesPass, failure or abort
Failure detailValidity, segment and LBAUse only valid fields
LBA
Logical Block Address

Worked interpretation: Short and extended tests have different reset/power continuity rules.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3

Review the terminology when needed
Controller / namespace
A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
SQ / CQ / SQE / CQE
Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
Register / Identify / Feature / Log
A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
index / offset / zero-based
An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
Scope / reset / retention
Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.

Questions in this volume

  1. Q149 · How are self-test support and coverage established?
  2. Q150 · How do short and extended self-tests differ?
  3. Q151 · What happens when self-test is restarted or cancelled?
  4. Q152 · How are current operation and completion percentage interpreted?
  5. Q153 · How are self-test outcomes and interruption effects interpreted?
  6. Q154 · Does every self-test completion generate an AER?
  7. Q155 · When are segment, diagnostic and failing-LBA fields valid?
  8. Q156 · How are the 20 self-test results ordered and replaced?

Q149 How are self-test support and coverage established?

Follow the explanation

Self-test diagnoses controller and selected media internally; it does not replace complete host data validation.

1. Select the target and information

NSID 0 tests the controller, an active ID includes that namespace andFFFFFFFFh includes namespaces accessible through that controller at start.

NSID
Namespace Identifier

OACS establishes support, DSTO.SDSO concurrency scope and EDSTT extended-test duration.

STC selects the test action and LID 06h reports current operation and 20 results.

LID
Log Page Identifier

2. Query sequence and interpretation

Establish support/state, preserve the old log, then start and monitor the selected test.

Initiation success starts background testing; passing requires a new result with DSTR0.

3. Handle missing or inconsistent evidence

Invalid NSID uses Invalid Namespace/Format; an inactive NSID uses Invalid Field. Keep the cases distinct.

NSID
Namespace Identifier

Match OACS, STC, target and logged test code.

First distinguish an invalid ID from an existing inactive namespace.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q150 How do short and extended self-tests differ?

Follow the explanation

They offer different diagnostic duration/depth; segment contents are vendor-defined and the illustrated RAM/media checks are informative examples.

1. What differs

Both use NSID coverage and can affect other work through shared resources.

STC1/2 selects short/extended; DSTOS identifies the current test and DSTCS its percentage.

2. How to choose and verify

EDSTT reports extended duration; short tests should finish within two minutes. Preserve the strength of these recommendations.

Select depth/impact, record start and monitor; commands requiring suspension run between test suspension and resumption.

Results determine pass/failure; a short pass does not guarantee an extended pass.

3. Conditions that shape the comparison

Reset is a crucial difference: CLR aborts short tests, while extended tests persist across CLR and resume after restored power.

Account for other work/suspension when reviewing timing and apply the distinct reset rules.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q151 What happens when self-test is restarted or cancelled?

Follow the explanation

Concurrency is limited and STCFh explicitly cancels the background self-test operation.

1. Distinguish the failure conditions

SDSO0 checks controller-level concurrency andSDSO1 subsystem-level concurrency.

STC1/2/3 start operations, Fh cancels andEh has vendor-specific interactions.

Starting 1/2/3 while a test is active returns 1/1Dh rather than silently restarting it.

2. Establish the cause from evidence

Read DSTO and LID 06h; local host command tracking cannot rule out an already running background test.

LID
Log Page Identifier

With an active test, cancellation precedes a new result, idle state and command completion.

3. Outcome and follow-up checks

Cancelling with no test succeeds without changing the log.

Verify log update ordering and DSTR1 rather than idle alone.

First distinguish STCFh from Abort targeting an already completed initiation command.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q152 How are current operation and completion percentage interpreted?

Follow the explanation

The header describes current work while the result list describes finished tests; old results do not replace current progress.

1. Establish the source and scope

Query the appropriate test scope and retain sampling time.

Use LID 06h CDSTO/CDSTC/RDS1 after checking support.

2. Fields, units and worked interpretation

DSTOS0 is idle,1 short,2 extended,3 refresh; DSTCS25 means 25%, not 26%.

Read operation before percentage; ignore percentage when idle and inspect the latest result.

A short/extended result must be created before clearing DSTOS; idle plus new result establishes outcome.

3. Conditions that change the interpretation

A stationary percentage need not prove failure; segment work or suspension may explain it. Percentage does not replace outcome.

Compare operation, progress and result across snapshots rather than diagnosing a stall from one number.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q153 How are self-test outcomes and interruption effects interpreted?

Follow the explanation

Outcome codes distinguish diagnostic failure from host cancellation; resumed extended testing must not be mislabeled as failed due to reset alone.

1. Identify the trigger and affected objects

Results describe test instances and their code/time, not initiation-command status.

Read DSTR, DSTC, POH and valid diagnostic fields in LID 06h.

2. State changes and recovery

DSTR0 success;1 command cancellation;2 CLR;3 namespace removal;4 Format;5 fatal/unknown test error;6/7 segment failure;8 unknown abort;9 Sanitize.

Identify test type before matching interruption: CLR ends short testing but extended testing resumes and produces its final result later.

DSTR0 passes;7 provides a known failing segment. No new result can mean extended testing is still resuming.

3. Checks across reset or power loss

TriggerEffect on this operation or state
What survives or continues after Controller Reset?CLR aborts a short test but an extended test must persist and resume after reset. The resume segment is vendor-specific; implementations should only need to repeat the interrupted last segment.
What survives or continues after NVM Subsystem Reset?Subsystem reset causes CLR on covered controllers: short tests abort and extended tests resume. Rebuilding Admin Queues is not restarting the entire extended test.
What survives or continues after a power cycle?Extended testing must resume after power restoration; short testing has no such continuation requirement. Read operation/progress/results rather than requiring reset-aborted results for both.

4. Verify retention and recovery

There is no separate power-loss DSTR code; Format cancellation also depends on Figure 701 scope combinations.

Correlate external operations, test type and log cause.

First check extended-test continuation before expecting a reset-aborted entry.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q154 Does every self-test completion generate an AER?

Follow the explanation

Determine normal self-test completion from the Device Self-test Log. There is no generic Self-test Completed notice, so receiving an AER is not a completion requirement.

1. Where normal test completion is reported

Initiation completion and later background completion are distinct and do not automatically create an AER.

Monitor operation/new result; correlate any diagnostic-error event and additional error information.

Normal completion without AER can conform; an error event still does not replace detailed results.

2. Diagnostic Failure is a distinct notification

Check self-test/LID 06h support and the separate Diagnostic Failure error event.

Diagnostic Failure uses AET0/AEI02h and is distinct from DSTR.

Validate defined events rather than transplanting Sanitize completion semantics.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Related mechanisms: Q133

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q155 When are segment, diagnostic and failing-LBA fields valid?

Follow the explanation

Nonzero fields need not be valid; validity bits prevent false precision.

1. Establish the source and scope

SEGN identifies an internal test segment and FLBA a logical block; they are not interchangeable.

Read DSTR and VDINFO validity bits before the corresponding fields.

2. Fields, units and worked interpretation

SEGN is the first known failed segment only for DSTR7; FVLD validates one failing LBA under NVM semantics.

LBA
Logical Block Address

Check nonempty result and valid bits before mapping namespace/LBA; do not invent namespace association.

Reporting one of several failing LBAs is valid; completeness or lowest-LBA ordering is not guaranteed.

3. Conditions that change the interpretation

Ignore invalid fields rather than validating their range, while valid contradictory data remains significant.

Distinguish unknown location from an inconsistent valid location using validity and format.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Q156 How are the 20 self-test results ordered and replaced?

Follow the explanation

Fixed history supports recent diagnosis rather than a complete lifetime audit.

1. Mechanism and scope

LID 06h has 20 results of 28 bytes after a 4-byte current-status header.

RDS1 is newest through RDS20 oldest; unused entries have DSTRFh/DSTC0 and other fields ignored.

2. Understand it through actions and results

Use structural and empty-entry rules, not an all-zero test.

Snapshot RDS1, then verify insertion and older-result displacement; history beyond 20 is no longer included.

After the 21st result,20 structures still represent the recent history.

3. Avoid a misleading conclusion

STCFh with no active test leaves the log unchanged rather than inserting a synthetic cancellation result.

Compare code, outcome, hours and diagnostics rather than treating potentially repeated timestamps as unique IDs.

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Source locations for this question

Sources: Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §5.2.13.1.7 · NVM Command Set 1.3 §4.1.4.3 · Base 2.4 §5.2.14.2.1 · 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)

Back to questions

Source locations and existing figure guides

Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.

  • Base 2.4 · §3.7.1–3.7.4
    Printed pages 120–124 · PDF 146–150
  • Base 2.4 · §4.2.3
    Printed pages 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §5.2.2
    Printed pages 183–190 · PDF 209–216 · Figure 150–156
  • Base 2.4 · §5.2.2 (PCIe-applicable events)
    Printed pages 183–191 · PDF 209–217 · Figure 150–160
  • Base 2.4 · §5.2.6, 8.1.8
    Printed pages 199–201, 614–616 · PDF 225–227, 640–642 · Figure 176–180, 700–701
  • Base 2.4 · §5.2.13.1.2
    Printed pages 218–220 · PDF 244–246 · Figure 212
  • Base 2.4 · §5.2.13.1.7
    Printed pages 229–232 · PDF 255–258 · Figure 218–219
  • Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
    Printed pages 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
    Printed pages 340–387 · PDF 366–413 · Figure 338–341
  • NVM Command Set 1.3 · §4.1.4.3
    Printed pages 75–76 · PDF 75–76 · Figure 111

When you need a field guide

Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.

Original documents used
  • 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
Jia-Chang

Jia-Chang

Human

Recent posts

PCIe Chapter 37：效能推估與跨章觀察
PCIe Chapter 37: Performance Estimation and Integrated Observation
PCIe Chapter 36：交易依賴、ID-Based Ordering 與 Message
PCIe Chapter 36: Dependencies, ID-Based Ordering, and Messages

Comments

  Write a comment ...