NVMe Self-Study Bank: Reset and shutdown

NVMe · Q1–328

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

Q174–Q187

Reset and shutdown

Reset rebuilds an operating context while shutdown prepares stopping; compare scope, completion and retained operations.

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

Requested stop versus completed stop

A host request is not device completion; inspect reported state.

ActionRequestFollow-up
Controller resetCC.EN→0Wait RDY0 and rebuild queues
Subsystem resetApplicable reset interfaceRecover affected controllers
Normal shutdownCC.SHN=01bWait SHST10b and power-off scope
Abrupt shutdownCC.SHN=10bStill observe completion

Worked interpretation: Incomplete normal shutdown can qualify for UPL; completed abrupt shutdown need not. State at power loss matters.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.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. Q174 · How do controller, subsystem and queue resets differ?
  2. Q175 · How do PCIe reset types affect NVMe?
  3. Q176 · How do reset outcomes depend on ongoing activity?
  4. Q177 · How does RDY behave during reset?
  5. Q178 · What needs rebuilding after reset?
  6. Q179 · How are old outstanding commands handled after reset?
  7. Q180 · How is state revalidated after reset?
  8. Q181 · What if reset times out or CFS remains?
  9. Q182 · How is normal shutdown requested?
  10. Q183 · When is power removal appropriate?
  11. Q184 · How do normal, abrupt and unannounced loss differ?
  12. Q185 · What may remain outstanding during shutdown?
  13. Q186 · How do shutdown modes affect the former Unsafe Shutdowns counter?
  14. Q187 · Why inspect health, errors and persistent events after loss?

Q174 How do controller, subsystem and queue resets differ?

Follow the explanation

Choose recovery scope with known impact on ongoing work.

1. What differs

Queue reset recreates selected I/O queues; CLR resets a controller; subsystem reset covers its defined domains.

Use Delete/Create, clear CC.EN or write 4E564D65h to supported NSSR respectively.

2. How to choose and verify

Check NSSRS, domain topology and queue dependencies.

Quiesce, reset/rebuild and resume, respecting SQ/CQ dependencies.

SQ
Submission Queue
CQ
Completion Queue

Recovered resources begin a new valid lifetime.

3. Conditions that shape the comparison

Register reset has no CQE; queue-management commands do.

CQE
Completion Queue Entry

Verify affected resources rather than host function names.

4. Whether CQE, DNR and More apply here

CQE
Completion Queue Entry
DNR
Do Not Retry, a completion retry indication

Queue-reset Delete/Create commands have CQEs; CC.EN/NSSR register accesses do not. DNR/More therefore apply only to the command completions.

DNR
Do Not Retry, a completion retry indication

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q175 How do PCIe reset types affect NVMe?

Follow the explanation

Focus on NVMe-visible effects; reset source changes retention and activation.

1. What differs

FLR is function-level; Conventional Reset includes Hot/Fundamental forms, with topology determining affected controllers.

FLR
Function Level Reset

Conventional/FLR initiate CLR; CC.EN reset does not reset PCI configuration space.

FLR
Function Level Reset

2. How to choose and verify

Check reset support, CAP and pending firmware requirements.

Record source, restore applicable PCI configuration and initialize NVMe.

Rebuild affected queues; FLR does not preserve I/O queues.

3. Conditions that shape the comparison

FLR/CC.EN do not satisfy a required Conventional Reset.

Respect exceptions such as CMBMSC retention under FLR.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q176 How do reset outcomes depend on ongoing activity?

Follow the explanation

Channels and background operations can have different reset behavior.

1. Identify the trigger and affected objects

Queues end while data/management state follow specific rules.

Snapshot outstanding work, logs and reset source.

2. State changes and recovery

Sanitize continues, short tests abort, extended tests resume and uncommitted staging is discarded.

Record stage and reread state instead of stale CQE bytes.

Classify each operation as complete, stopped, continuing or unresolved.

3. Verify retention and recovery

Missing CQE does not prove no execution or rollback.

Apply per-function persistence.

First distinguish the command from its background work.

Sources: Base 2.4 §5.2.26–5.2.27 · Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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.26–5.2.27 · Base 2.4 §5.2.6, 8.1.8 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q177 How does RDY behave during reset?

Follow the explanation

RDY confirms disable/readiness, not just EN writes.

1. Prepare the operation

RDY is controller state, not universal namespace readiness.

Read CAP.TO and ready-mode/CRTO capabilities.

Wait RDY0 after disable and RDY1 after enable with proper deadlines.

2. Sequence and completion conditions

Complete disable/configuration before re-enabling.

Transitions and media restrictions follow the selected mode.

3. Handle unmet conditions

An inaccessible register is not RDY0 evidence.

Correlate request and acknowledgment with timing.

Sources: Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q178 What needs rebuilding after reset?

Follow the explanation

Rebuild by reset source and feature rules.

1. Prepare the operation

Queues/pointers reset separately from persistent configuration.

Check retention exceptions, features and queue allocation.

CC.EN reset preserves specified registers, not queue pointers.

2. Sequence and completion conditions

Restore transport/registers, initialize phase, enable/wait, configure and recreate queues.

New queues work and features restore correctly.

3. Handle unmet conditions

Retained addresses do not validate CQEs; non-saveable is not necessarily zero.

Compare values and exceptions rather than blanket zeroing.

Sources: Base 2.4 §4.4 · Base 2.4 §3.1.4 (AQA, ASQ, ACQ, CMBLOC) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §4.4 · Base 2.4 §3.1.4 (AQA, ASQ, ACQ, CMBLOC) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q179 How are old outstanding commands handled after reset?

Follow the explanation

Prevent stale-CID confusion and late effects.

1. Identify the trigger and affected objects

Separate lifetimes, including cross-controller recovery.

Preserve reset and old-command evidence.

2. State changes and recovery

Reinitialize phase/pointers, ignoring old-generation CQEs.

Establish termination before reclamation or mutating retries.

New commands use new results; assess prior data effects separately.

3. Verify retention and recovery

Lost communication precludes a universal abort-CQE requirement.

Distinguish fresh writes from residual bytes.

Inspect phase and CID reuse first.

CID
Command Identifier, unique among outstanding commands in one SQ

Sources: Base 2.4 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q180 How is state revalidated after reset?

Follow the explanation

RDY1 alone does not establish restored settings or background state.

1. Prepare the operation

Query each defined scope.

Use supported discovery interfaces.

Inspect feature values, namespace lists, firmware and operation logs.

2. Sequence and completion conditions

Discover state before resuming correctly configured I/O.

Explain differences such as continued sanitization with invalidated AERs.

3. Handle unmet conditions

Cleared entries and retained counters can both conform.

Compare persistent, restored and live fields appropriately.

Sources: Base 2.4 §4.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.38 · Base 2.4 §5.2.13.1.7 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §4.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.38 · Base 2.4 §5.2.13.1.7 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q181 What if reset times out or CFS remains?

Follow the explanation

Distinguish a wrong deadline from persistent failure.

1. Preserve the evidence first

Start locally and assess broader impact.

Preserve capability/state/source/timing.

Apply the correct deadlines and fatal-recovery rules.

2. Work through the possible causes

Verify deadline and role first.

Validate readings, reset controller and consider subsystem reset if appropriate.

3. Connect observations to specification conditions

Recovery includes usable channels, not only cleared CFS.

Avoid unjustified short deadlines or unsuitable subsystem resets.

Exclude expected Offline-secondary CFS.

Sources: Base 2.4 §9.1–9.6.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §9.1–9.6.1 · Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.1.4 (CRTO) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q182 How is normal shutdown requested?

Follow the explanation

Normal shutdown prepares media, unlike disable.

1. Prepare the operation

Coordinate controllers in CAP.CPS power scope.

Read power scope, latency and shutdown status.

SHN01b requests normal shutdown; SHST10b/ST0 confirms it.

2. Sequence and completion conditions

Quiesce/drain, delete SQs then CQs, request shutdown and wait.

Readiness persists until a defined state-changing event.

3. Handle unmet conditions

SHN has no CQE; commands may be aborted for power-loss notification.

Verify acknowledgment rather than request alone.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q183 When is power removal appropriate?

Follow the explanation

Notification is not completed preparation.

1. Prepare the operation

All controllers in the power scope must be ready.

Inspect status, scope and latency guidance.

SHST01b/10b mean processing/complete with ST0 for controller shutdown.

2. Sequence and completion conditions

Poll completion; the one-second guidance for RTD3E0 is not unconditional removal permission.

Establish readiness across the required scope.

3. Handle unmet conditions

Later reset/media access can invalidate readiness.

Correlate latest state with actual loss.

Sources: Base 2.4 §3.1.4 (CAP, VS) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.1.4 (CAP, VS) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q184 How do normal, abrupt and unannounced loss differ?

Follow the explanation

Both shutdown types notify; unannounced loss may not.

1. What differs

Work/persistence opportunities differ within the required power scope.

Both modes report completion through SHST10b.

2. How to choose and verify

Preserve shutdown, power and counter evidence.

Normal drains/deletes; abrupt stops new I/O/notifies; sudden loss cannot wait.

Ready abrupt shutdown does not increment UPL merely by name.

3. Conditions that shape the comparison

Procedure names do not guarantee outstanding-write persistence.

Observe request, completion and actual loss.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q185 What may remain outstanding during shutdown?

Follow the explanation

Continued I/O obstructs orderly shutdown.

1. Mechanism and scope

Pending AERs are not pending data writes.

Drain I/O; Admin abortion is host policy, with only AERs recommended outstanding at completion.

2. Understand it through actions and results

Inspect command tracking and shutdown state.

Quiesce/process results, request shutdown and avoid disrupting it with EN clearing.

Complete shutdown can coexist with pending AERs.

3. Avoid a misleading conclusion

Late commands may be aborted for power-loss notification.

Exclude AERs from data-drain expectations.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q186 How do shutdown modes affect the former Unsafe Shutdowns counter?

Follow the explanation

Base 2.4 calls it UPL and counts actual loss conditions.

1. Mechanism and scope

UPL is lifetime information, not per-shutdown status.

Increment with SHST≠10b at loss or the defined Ignore Shutdown/media exception.

2. Understand it through actions and results

Read bytes 144–159 and preserve pre-loss state.

Baseline, request/wait, remove power and compare, recording intervening activity.

Ready normal/abrupt shutdown does not increment by name; premature loss does.

3. Avoid a misleading conclusion

Reset alone is not a power-loss count.

Apply exact conditions, excluding extra losses and wrong samples.

Sources: Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · 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

Q187 Why inspect health, errors and persistent events after loss?

Follow the explanation

Counters/errors/history help reconstruct the missing-completion interval.

1. Preserve the evidence first

Match identity and cumulative/live state.

Check supported events and correct log selection.

Inspect power/error counters and reset/operation events.

2. Work through the possible causes

Preserve the first recovered snapshot.

Preserve logs before generating additional history.

3. Connect observations to specification conditions

Absence of an error entry does not establish data safety.

Cleared entries can conform while counters persist.

Correlate timelines without one-to-one record assumptions.

Sources: Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2

Source locations for this question

Sources: Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events) · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.6–3.6.1 (memory-based scope and shutdown) · PCIe Transport 1.4 §3.3 · Base 2.4 §5.2.13.1.3 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2

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.1.4 (CAP, VS)
    Printed pages 54–59 · PDF 80–85 · Figure 36–37
  • Base 2.4 · §3.1.4 (CC, CSTS, NSSR)
    Printed pages 60–66 · PDF 86–92 · Figure 41–43
  • Base 2.4 · §3.1.4 (AQA, ASQ, ACQ, CMBLOC)
    Printed pages 66–68 · PDF 92–94 · Figure 44–47
  • Base 2.4 · §3.1.4 (CRTO)
    Printed pages 72–73 · PDF 98–99 · Figure 57
  • Base 2.4 · §3.6–3.6.1 (memory-based scope and shutdown)
    Printed pages 113–115 · PDF 139–141 · Figure 85
  • Base 2.4 · §3.7.1–3.7.4
    Printed pages 120–124 · PDF 146–150
  • Base 2.4 · §3.11–3.11.1, 5.2.9–5.2.10
    Printed pages 135–138, 202–206 · PDF 161–164, 228–232 · Figure 187–193
  • Base 2.4 · §4.2.3
    Printed pages 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §4.4
    Printed pages 166–169 · PDF 192–195 · Figure 126–127
  • Base 2.4 · §5.2.2
    Printed pages 183–190 · PDF 209–216 · Figure 150–156
  • 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.3
    Printed pages 220–225 · PDF 246–251 · Figure 213–214
  • 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.13.1.38
    Printed pages 313–320 · PDF 339–346 · Figure 312
  • Base 2.4 · §5.2.26–5.2.27
    Printed pages 448–454 · PDF 474–480 · Figure 451–455
  • Base 2.4 · §9.1–9.6.2.1 (PCIe-applicable rules; stop before 9.6.2.2)
    Printed pages 825–828 · PDF 851–854
  • Base 2.4 · §9.1–9.6.1
    Printed pages 825–826 · PDF 851–852
  • PCIe Transport 1.4 · §3.3
    Printed pages 11–12 · PDF 11–12

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 ...