NVMe Self-Study Bank: Asynchronous Event Request
read more
NVMe Self-Study Bank: Asynchronous Event Request
NVMe · Q1–328
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Q82–Q92
Asynchronous Event Request
AER preposts requests that complete on events. Connect requests, events, logs and acknowledgment before concurrency and rearming.
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
Notification completion is not the end
An AER supplies event identity; logs provide detail and current state.
| Stage | Action | Evidence |
|---|---|---|
| Before event | Host submits AER | Request identity and AERL+1 limit |
| Event occurs | Controller completes a request | Type, information, LID |
| Inspect | Host reads matching log | Selectors, RAE and raw data |
| Continue | Host posts another AER | New outstanding request |
- LID
- Log Page Identifier
Worked interpretation: AERL3 allows four requests. Replace a completed request; a completed unrearmed request cannot receive another event.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.30.1.6
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
- Q82 · Why post Asynchronous Event Requests before events, and why do they remain outstanding?
- Q83 · How does AER completion identify the event and its log?
- Q84 · Why read the associated log and post another AER after an event?
- Q85 · What happens when outstanding AERs exceed the controller limit?
- Q86 · How are events handled when no AER is outstanding?
- Q87 · How can concurrent identical or different events be combined and reported?
- Q88 · How does Asynchronous Event Configuration enable or disable notifications?
- Q89 · What notification conditions apply to SMART, namespaces, firmware, telemetry, sanitize, self-test and PEL?
- Q90 · How does reading a log clear or retain an event?
- Q91 · Can AER be aborted, and what happens to pending requests during reset?
- Q92 · How should an AER be investigated when the associated log lacks expected information?
Q82 Why post Asynchronous Event Requests before events, and why do they remain outstanding?
Follow the explanation
AER provides a request the controller can complete to report an event. It is not an unsolicited ordinary completion without a corresponding request, so the host posts requests in advance.
1. Mechanism and scope
Each AER belongs to its controller and Admin Queue. It waits for an event rather than reading or writing a namespace.
Command-specific fields are reserved; allocate a unique outstanding Admin CID. Event completion supplies AET/AEI/LID in DW0 and event-specific DW1 where defined.
- CID
- Command Identifier, unique among outstanding commands in one SQ
2. Understand it through actions and results
Identify.AERL+1 limits outstanding requests. OAES and FID 0Bh govern optional notifications; AERL is not an event-type count.
- FID
- Feature Identifier
After initialization and notification setup, post requests within the limit. Preserve a returned event, handle and acknowledge it, then replenish the request pool.
Remaining outstanding without events is normal; the host should not assign an ordinary timeout. AER does not need periodic success completions as a liveness signal.
3. Avoid a misleading conclusion
Exceeding the outstanding limit can produce Asynchronous Event Request Limit Exceeded (1/05h). Waiting without an event is not a specified timeout error.
Compare outstanding request count, AERL, notification configuration and event conditions rather than elapsed seconds alone.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.30.1.6 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.30.1.6 · 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)
Q83 How does AER completion identify the event and its log?
Follow the explanation
A successful status completes the AER; the actual event is in its command-specific result. Decode that result to select the next log.
1. Establish the source and scope
Match the request by SQID/CID before decoding the controller’s event; another Admin command’s DW0 need not use the AER format.
- SQID
- Submission Queue Identifier
- CID
- Command Identifier, unique among outstanding commands in one SQ
Capabilities and event tables define the supported events. Decode AET first to select the AEI table.
2. Fields, units and worked interpretation
DW0[2:0] is AET, [15:8] AEI and [23:16] LID. DW1 is event-specific; do not assume it is NSID without a definition.
- NSID
- Namespace Identifier
Validate phase and identity, then SCT/SC. For normal event completions, decode the event and follow its associated read or handling rule.
- SCT
- Status Code Type
Firmware Activation Starting is a Notice pointing to Firmware Slot Information; it signals starting, not completion. Sanitize events additionally use their defined DW1 target.
3. Conditions that change the interpretation
Do not decode arbitrary DW0 as an event when the AER itself failed. Identical AEI values can mean different things under different AETs.
Preserve raw CQE and subsequent log, checking LID and target instead of retaining only a translated message.
- CQE
- Completion Queue Entry
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Source locations for this question
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §4.2.1, 4.2.3–4.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q84 Why read the associated log and post another AER after an event?
Follow the explanation
Reading the log obtains and acknowledges event information; posting AER supplies the next response opportunity. Missing either can stall future notification.
1. Prepare the operation
Ordinary reported event types are automatically masked until acknowledged. Immediate and One-Shot events have separate clearing behavior.
Check the event’s LID, RAE rule and enablement. AERL limits outstanding requests; it does not unmask events.
Ordinary acknowledgment uses Get Log Page with RAE=0; RAE=1 retains the event. The replacement AER is another Admin command with a valid CID.
2. Sequence and completion conditions
This path applies to ordinary events acknowledged through a log; Immediate and One-Shot events follow their own rules.
- Receive an AER completion → preserve it
Record the event type, information and LID before reading diagnostic content.
- Acknowledge under the event’s rules
Typically acknowledge with a successful Get Log Page using RAE=0. RAE=1 retains the event, and a failed read does not acknowledge it.
- Maintain outstanding AERs
Replenish requests for later notifications; a new request does not itself acknowledge the earlier event.
A persistent warning may notify again. Consider thresholds or notification settings before acknowledgment; verify preservation, acknowledgment and pending requests separately.
3. Handle unmet conditions
Failed reads retain the event; an attempted RAE=0 request is not success. One-Shot events clear on reporting and follow their specific handling.
Verify evidence preservation, successful acknowledgment and an available AER separately; one status does not prove all three.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · 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)
Q85 What happens when outstanding AERs exceed the controller limit?
Follow the explanation
The limit bounds waiting request resources, not the number of possible events.
1. Distinguish the failure conditions
It applies to concurrent outstanding AERs on this controller, not lifetime submissions across the subsystem.
Track CID and submission/completion times. Completed requests no longer consume the limit; update tracking before replenishing.
Excess AERs use Asynchronous Event Request Limit Exceeded (1/05h), not Abort Command Limit Exceeded (1/03h).
2. Establish the cause from evidence
AERL is zero-based: AERL=3 permits four outstanding requests.
Read AERL and post within the limit. For an excess-request test, add one while controlling concurrent event completions that could free a slot.
3. Outcome and follow-up checks
Within the limit, requests wait normally. A concurrent completion can make a later request valid; total submission count is insufficient.
Compare AERL+1 against concurrent outstanding counts and account for slots freed by event completions.
First check the +1 conversion and removal of completed requests from the outstanding set.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · 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)
Q86 How are events handled when no AER is outstanding?
Follow the explanation
Distinguish occurrence from delivery. No request does not imply no event, but not every event must wait indefinitely.
1. Mechanism and scope
Ordinary, Immediate and One-Shot events differ; establish enablement and masking first.
Ordinary pending information can supply a later AER. Immediate events require an outstanding request at occurrence and must not be reported otherwise.
2. Understand it through actions and results
Check OAES, FID 0Bh, event type and request history. Log support alone does not enable every related event.
- FID
- Feature Identifier
Trigger an enabled ordinary event without a request, then post AER. A clearing log read or CLR in between removes the basis for expecting the old notification.
For enabled ordinary events, the specification recommends retaining information for the next request. This is should, not unconditional permanent retention for all event classes.
3. Avoid a misleading conclusion
Absence of a request does not create an error CQE. Omitting an Immediate event under these conditions is required, not a firmware notification-loss defect.
- CQE
- Completion Queue Entry
Correlate occurrence, request, acknowledgment and CLR times to determine whether a notification should remain pending.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · 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)
Q87 How can concurrent identical or different events be combined and reported?
Follow the explanation
Notification can consolidate conditions while preserving actionable information. Occurrences, log entries and AER completions need not correspond one-to-one.
1. Mechanism and scope
Events of the same type with identical responses may be combined. Different types or responses have a queuing recommendation; automatic masking also affects reporting.
Compare AET, AEI, LID and event-specific parameters, not AEI alone.
2. Understand it through actions and results
Establish support/enablement and available request count. One request cannot simultaneously yield several independent completions.
Trigger known conditions, preserve responses and process logs/replenish requests. Check acknowledgment before expecting further notifications of a masked type.
Combining identical responses is permitted; queuing differing responses is recommended. AER order does not thereby provide a precise timeline of every internal occurrence.
3. Avoid a misleading conclusion
Legitimate consolidation is not a missing-completion error. Excess requests separately invoke 1/05h handling.
Use log records or generations to supplement notifications rather than treating AER count as fault count.
Sources: 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.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)
Q88 How does Asynchronous Event Configuration enable or disable notifications?
Follow the explanation
FID 0Bh selects applicable notifications. It neither removes the underlying condition nor submits AERs automatically.
1. Prepare the operation
It configures specified SMART and optional notifications on a controller, not a universal switch for all Error events.
Check OAES and applicable support, then Current FID 0Bh. Configuration enablement and automatic pending-event masking are separate states.
Set CDW11 enables notification bits; Get returns Current. The bitmap is not the AET/AEI encoding of an AER completion.
2. Sequence and completion conditions
Set valid bits, await success, read Current, ensure a pending AER and establish the condition. Conditions already true at enablement follow the feature’s rules as well.
Success establishes configuration; delivery still depends on condition, masking and requests. Disabling notification does not necessarily clear the warning itself.
3. Handle unmet conditions
Enabling unsupported events returns Invalid Field (0/02h). Lack of an available AER is not a Set Features failure status.
Correlate support, current mask, actual condition and AER availability. Set success alone does not validate the whole notification path.
Sources: Base 2.4 §5.2.30.1.6 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · 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.30.1.6 · Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.14.2.1 · 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)
Q89 What notification conditions apply to SMART, namespaces, firmware, telemetry, sanitize, self-test and PEL?
Follow the explanation
Correct the assumption that every function has a completion AER. Events require an actual specification definition; having a log is insufficient.
1. When the event exists and who observes it
Events can describe controller health, namespace changes, activation or sanitization targets. Match the affected scope, not only the receiving controller.
Use OAES, FID 0Bh and event tables. Self-test or PEL support does not automatically define a generic Self-test Completed or PEL Changed AER.
SMART uses 02h; attached/allocated namespace changes use 04h/1Ch; activation starting uses 03h; telemetry changes use 08h; sanitize events use 81h.
2. Notification, reading and acknowledgment
Identify the event condition before selecting its log. Normal self-test completion is established from 06h; a separately applicable Diagnostic Failure uses the Error event rules.
Sanitize distinguishes completion, unexpected deallocation and entry into Media Verification. Activation Starting likewise does not establish final activation success.
3. Evaluate missing notifications or records
Absence of an undefined completion event is not an error. A missing-event claim must establish the defined event, support, enablement and request conditions.
Compare operation results, dedicated logs and AER conditions separately, then supplement with supported PEL events; they need not map one-to-one.
First verify that the expected event is actually defined in this revision.
4. Asynchronous Event notification conditions
AER reports an event by completing a request. Read the complete conditions in this volume
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.7 · 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 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2
Source locations for this question
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.7 · 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 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2
Q90 How does reading a log clear or retain an event?
Follow the explanation
Acknowledgment controls further reporting; it does not erase all history or repair the cause. The underlying warning may remain.
1. Prepare the operation
Use the event’s specified log and target. Reading another log or target need not acknowledge it.
Establish ordinary log-based acknowledgment versus Immediate/One-Shot behavior before applying RAE.
RAE=0 clears the associated event on success; RAE=1 retains it. LID, NSID and other selectors still must identify the correct log view.
- NSID
- Namespace Identifier
2. Sequence and completion conditions
Preserve notification and state, retain where needed with RAE=1, and acknowledge via the applicable successful RAE=0 read. Do not invent a universal partial-read acknowledgment rule.
Successful acknowledgment unmasks as defined; a continuing condition can recur. RAE retains the event, not necessarily a frozen data snapshot.
3. Handle unmet conditions
Failed Gets must retain the event regardless of the requested RAE=0.
Correlate successful completion time, RAE, mask state and later notifications. Current state can differ from event-time state without invalidating acknowledgment.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · 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)
Q91 Can AER be aborted, and what happens to pending requests during reset?
Follow the explanation
AER has an Admin CID despite not having an ordinary timeout. Distinguish a targeted Abort from resetting the whole controller.
1. Identify the trigger and affected objects
Target the AER with SQID=0 and its CID; controller reset affects all its outstanding AERs.
- SQID
- Submission Queue Identifier
ACL+1 limits concurrent Aborts, independently of AERL+1. Aborting AER has no universal success guarantee beyond Abort semantics.
2. State changes and recovery
Track the Abort CID, target CID and IANP. IANP=0 identifies immediate abort; IANP=1 does not rule out a later deferred abort.
Process Abort and target results separately. If resetting instead, terminate old tracking under reset rules and post new AERs after recovery without waiting for reset-aborted CQEs.
An event can win the race and complete normally. An aborted target reports Command Abort Requested; a controller-reset-aborted AER must not return a CQE. These outcomes differ.
3. Checks across reset or power loss
| Trigger | Effect on this operation or state |
|---|---|
| What survives or continues after Controller Reset? | Controller Reset aborts outstanding AERs without CQEs. Controller Level Reset also clears pending notifications. After recovery submit fresh requests and read retained state under each log’s rules. |
4. Verify retention and recovery
Excess Abort commands may return 1/03h. A missing/already-completed target does not universally make Abort fail; inspect IANP and target completion history.
Correlate CIDs within one Admin Queue lifetime so reused post-reset CIDs are not mistaken for old targets.
First identify event completion, Abort or reset termination before deciding whether a CQE is expected.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.1 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.1 · 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)
Q92 How should an AER be investigated when the associated log lacks expected information?
Follow the explanation
Notifications describe an occurrence; logs may show current state or bounded history rather than a same-time copy. Identify the data model before claiming inconsistency.
1. Preserve the evidence first
Fix controller, target and interface. Another host may have read or acknowledged shared state outside the local trace.
Check the event definition/LID and the log’s update, clearing and retention rules. Not every event creates an entry.
Preserve CQE, selectors, RAE, time and valid fields. SMART Critical Warning reflects Get processing time and may differ from event-time state.
2. Work through the possible causes
First distinguish current-state logs from event history; that determines whether event-time values must remain visible.
Exclude wrong log/target, intervening reads/reset, generation changes and recovered transient conditions before testing a specific retention requirement.
3. Connect observations to specification conditions
Temperature can trigger an event and fall before SMART is read. Conversely, a More=1 command error calls for correlatable supplemental information under its own rules.
Missing expected data does not rewrite the successful AER status. Preserve a subsequent Get failure separately.
Establish the event condition, log time model and intervening actions. A contradiction requires the relevant retention preconditions to hold.
Sources: Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · 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.2 (PCIe-applicable events) · Base 2.4 §5.2.13–5.2.13.1.1 · Base 2.4 §5.2.13.1.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Shared rules linked from the answers
Each shared mechanism is explained in full once in this volume. Use browser Back to return to the question; explicit command or feature exceptions take precedence.
Shared conditions for this topic · Is an asynchronous event generated?
AER reports an event by completing a request. Distinguish the event condition, enablement, masking and available requests; submitting AER does not enable every optional event.
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.1, 4.2.3–4.2.4
Printed pages 144–157 · PDF 170–183 · Figure 97–105, 109 - Base 2.4 · §4.2.3
Printed pages 145–155 · PDF 171–181 · Figure 101–105 - Base 2.4 · §5.2.1
Printed pages 181–182 · PDF 207–208 · Figure 147–149 - 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.13–5.2.13.1.1
Printed pages 212–218 · PDF 238–244 · Figure 203–211 - 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.14.2.1
Printed pages 340–387 · PDF 366–413 · Figure 338–341 - Base 2.4 · §5.2.30.1.6
Printed pages 466–468 · PDF 492–494 · Figure 474
When you need a field guide
Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.
- Base 2.4 Figure 101 · Completion Queue Entry: Status Field
- Base 2.4 Figure 104 · Status Code – Command Specific Status Values
- Base 2.4 Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
- Base 2.4 Figure 97 · Common Completion Queue Entry Layout – Admin and All I/O Command Sets
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
Comments