5.2 Asynchronous Event Request command
Asynchronous events are used to notify host software of status, error, and health information as these events occur. To enable asynchronous events to be reported by the controller, host software needs to submit one or more Asynchronous Event Request commands to the controller. The controller specifies an event to the host by completing an Asynchronous Event Request command. Host software should expect that the controller may not execute the command immediately; the command should be completed when there is an event to be reported.
The Asynchronous Event Request command is submitted by host software to enable the reporting of asynchronous events from the controller. This command has no timeout. The controller posts a completion queue entry for this command when there is an asynchronous event to report to the host. If Asynchronous Event Request commands are outstanding when the controller is reset, the commands are aborted.
All command specific fields are reserved.
Host software may submit multiple Asynchronous Event Request commands to reduce event reporting latency. The total number of simultaneously outstanding Asynchronous Event Request commands is limited by the Asynchronous Event Request Limit specified in the Identify Controller data structure in Figure 109.
Asynchronous events are grouped into event types. The event type information is indicated in Dword 0 of the completion queue entry for the Asynchronous Event Request command. When the controller posts a completion queue entry for an outstanding Asynchronous Event Request command and thus reports an asynchronous event, subsequent events of that event type are automatically masked by the controller until the host clears that event. An event is cleared by reading the log page associated with that event using the Get Log Page command (see section 5.14).
The following event types are defined:
Error event: Indicates a general error that is not associated with a specific command. To clear this event, host software reads the Error Information log (refer to section 5.14.1.1) using the Get Log Page command with the Retain Asynchronous Event field cleared to ‘0’.
SMART / Health Status event: Indicates a SMART or health status event. To clear this event, host software reads the SMART / Health Information log (refer to section 5.14.1.2) using Get Log Page with the Retain Asynchronous Event field cleared to ‘0’. The SMART / Health conditions that trigger asynchronous events may be configured in the Asynchronous Event Configuration feature using the Set Features command (see section 5.21).
I/O Command Set events: Events that are defined by an I/O command set.
NVM Command Set Events:
Reservation Log Page Available event: Indicates that one or more Reservation Notification log pages (refer to section 5.14.1.9.1) are available. To clear this event, host software reads the Reservation Notification log page using the Get Log Page command with the Retain Asynchronous Event field cleared to ‘0’.
Sanitize Operation Completed event: Indicates that a sanitize operation has completed and status is available in the Sanitize Status log page (refer to section 5.14.1.9.2). To clear this event, host software reads the Sanitize Status log page using the Get Log Page command with the Retain Asynchronous Event field cleared to ‘0’.
Vendor Specific event: Indicates a vendor specific event. To clear this event, host software reads the indicated vendor specific log page using Get Log Page command with the Retain Asynchronous Event field cleared to ‘0’.
Asynchronous events are reported due to a new entry being added to a log page (e.g., Error Information log) or a status update (e.g., status in the SMART / Health log). A status change may be permanent (e.g., the media has become read only) or transient (e.g., the temperature exceeded a threshold for a period of time). Host software should modify the event threshold or mask the event for transient and permanent status changes before issuing another Asynchronous Event Request command to avoid repeated reporting of asynchronous events.
If the controller needs to report an event and there are no outstanding Asynchronous Event Request commands, the controller should send a single notification of that Asynchronous Event Type when an Asynchronous Event Request command is received. If a Get Log Page command clears the event prior to receiving the Asynchronous Event Request command or if a power off condition occurs, then a notification is not sent.
5.2 Asynchronous event request commands
Asynchronous events are used to notify the host software of status, errors, and operating status information when these events occur. In order for the controller to report asynchronous events, the host software needs to submit one or more asynchronous event request commands to the controller. The controller assigns an event to the host by completing the "Asynchronous Event Request" command. The host software should expect that the controller may not execute the command immediately; when there is an event to report, the command should be completed.
Asynchronous event request commands are submitted by the host software to enable the reporting of asynchronous events from the controller. This command did not time out. When there is an asynchronous event to report to the host, the controller will issue a completion queue entry for this command. If the "Asynchronous Event Request" commands are not completed when the controller is reset, these commands will be aborted.
All command specific fields are reserved.
The host software can submit multiple asynchronous event request commands to reduce the event reporting delay. At the same time, the total number of outstanding asynchronous event request commands is limited by the asynchronous event request limit specified in the "identification controller" data structure of FIG. 109.
Asynchronous events are divided into event types. The event type information is indicated in Dword 0 of the completion queue entry of the asynchronous event request command. When the controller issues a completion queue entry for an outstanding asynchronous event request command and therefore reports an asynchronous event, the controller automatically blocks subsequent events of that event type until the host clears the event. Clear the event by reading the log page associated with the event using the "Get Log Page" command (see section 5.14).
The following event types are defined:
Error event: indicates a general error that is not related to a specific command. To clear this event, the host software uses the "Get Log Page" command to clear the "Keep Asynchronous Events" field to "0" to read the error message log (see 5.14.1.1)
SMART / Health Status Event: Indicates SMART or health status event. To clear this event, the host software uses the "Get Log Page" and clears the "Keep Asynchronous Events" field to "0" to read the SMART / Health Information Log (see 5.14.1.2). You can use the "Setup Function" command to configure the SMART / Run Status that triggers asynchronous events in the "Asynchronous Event Configuration" function (see Section 5.21).
I / O command set events: Events defined by the I / O command set.
NVM command set events:
Reserved log page available events: Indicates that one or more reserved notification log pages (see section 5.14.1.9.1) are available. To clear this event, the host software will use the "Get Log Page" command to read the "Retention Notification" page and clear the "Retain Asynchronous Event" field to "0".
Cleanup operation completed event: indicates that the cleanup operation is completed and there is a status available in the "Cleanup Status" log page (see section 5.14.1.9.2). To clear this event, the host software uses the "Get Log Page" command to clear the "Keep Asynchronous Events" field to "0" to read the "Clear Status" log page.
Vendor specific events: Indicate vendor specific events. To clear this event, the host software uses the "Get Log Page" command to clear the "Keep Asynchronous Events" field to "0" to read the indicated vendor-specific log page.
As new entries are added to the log page (for example, error message logs) or status updates (for example, the status in the SMART / Health log), asynchronous events are reported. The state change may be permanent (for example, the media has become read-only), or it may be transient (for example, the temperature exceeds the threshold for a period of time). The host software should modify the event threshold or mask events for transient and permanent state changes before issuing another "asynchronous event request" command to avoid repeated reporting of asynchronous events.
If the controller needs to report an event and there are no outstanding asynchronous event request commands, the controller should send a single notification of the asynchronous event type when the asynchronous event request command is received. If the "Get Log Page" command clears the event before receiving the "Asynchronous Event Request" command, or a power outage occurs, no notification will be sent.
5.2.1 Command Completion
A completion queue entry is posted to the Admin Completion Queue if there is an asynchronous event to report to the host. Command specific status values associated with Asynchronous Event Request are defined in Figure 45.
5.2.1 Command completion
If there are asynchronous events to report to the host, the completion queue entry will be posted to the "management completion queue". The command specific status values associated with asynchronous event requests are defined in Figure 45.
Dword 0 of the completion queue entry contains information about the asynchronous event. The definition of Dword 0 of the completion queue entry is in Figure 46.
Dword 0 of the completed queue entry contains information about asynchronous events. The definition of Dword 0 to complete the queue entry is shown in Fig. 46.
The information in either Figure 47, Figure 48, or Figure 50 is returned in the Asynchronous Event Information field, depending on the Asynchronous Event Type.
Depending on the type of asynchronous event, the information in Figure 47, Figure 48, or Figure 50 is returned in the "Asynchronous Event Information" field.
