27.10.2015 Views

Advanced Configuration and Power Interface Specification

ACPI_6.0

ACPI_6.0

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Advanced</strong> <strong>Configuration</strong> <strong>and</strong> <strong>Power</strong> <strong>Interface</strong> <strong>Specification</strong><br />

Where the Error Log Address Range does reside in NVRAM, OSPM requires no platform support to<br />

read persisted error records. OSPM can scan the Error Log Address Range on its own <strong>and</strong> retrieve<br />

the error records it previously persisted.<br />

18.5.2.3 Clearing<br />

After OSPM has finished processing an error record, it will notify the platform by clearing the<br />

record. This allows the platform to delete the record from the persistent store or mark it such that the<br />

space is free <strong>and</strong> can be reused. The following steps are executed by OSPM to clear an error record:<br />

1. Executes a BEGIN_ CLEAR_OPERATION action to notify the platform that a record clear<br />

operation is beginning.<br />

2. Executes a SET_RECORD_IDENTIFER action to inform the platform which error record is to<br />

be cleared. This value must not be set to 0x0 (unspecified).<br />

3. Executes an EXECUTE_OPERATION action to instruct the platform to begin the clear<br />

operation.<br />

4. Busy waits by continually executing CHECK_BUSY_STATUS action until FALSE is returned.<br />

5. Executes a GET_COMMAND_STATUS action to determine the status of the clear operation.<br />

6. Execute an END_OPERATION to notify the platform that the record read operation is<br />

complete.<br />

The platform carries out a clear request by performing the following steps:<br />

1. Sets some internal state to indication that it is busy. OSPM polls by executing a<br />

CHECK_BUSY_STATUS action until the operation is completed.<br />

2. Using the record identifier supplied by OSPM through the SET_RECORD_IDENTIFIER<br />

operation, determine which error record to clear. This value may not be 0x0 (unspecified).<br />

3. Locate the specified error record on the persistent store.<br />

4. Mark the record as free by updating the Attributes in its serialization header.<br />

5. Update internal record count.<br />

6. Clear internal busy state so when OS<br />

7. PM executes CHECK_BUSY_STATUS, the result indicates that the operation is complete.<br />

When the Error Log Address Range resides in NVRAM, the OS requires no platform support to<br />

Clear error records.<br />

18.5.2.4 Usage<br />

This section describes several possible ways the error record serialization mechanism might be<br />

implemented.<br />

18.5.2.4.1 Error Log Address Range Resides in NVRAM<br />

If the Error Log Address Range resides in NVRAM, then when OSPM writes a record into the<br />

logging range, the record is automatically persistent <strong>and</strong> the busy bit can be cleared immediately. On<br />

a subsequent boot, OSPM can read any persisted error records directly from the persistent store<br />

range. The size of the persistent store, in this case, is expected to be enough for several error records.<br />

740 April, 2015 Version 6.0

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!