Pre OS Test Descriptions
Last updated on September 22, 1999

Pre OS PCI Tests

PCIDUMP


Type Manual
Operating system Pre OS (Command Mode)
Log filename pcidump.log
Processing time Approximately 2 minutes
Status Required
Included in these HCTs: 9.x

PCIDUMP is not a test, it is a utility that is used to hold the ACPI namespace data for the test system for use in the pre OS PCI testing suite.

PCI Power Management Register Interface Test (PCICAP)


Type Manual
Operating system Pre OS (Command Mode)
Log filename pcicap.log
Status Required
Included in these HCTs: 9.x

The purpose of the PCICAP test is to probe PCI configuration space for each of the PCI device functions and verify that the power management registers for the network adapter, modem, graphics controller, and audio controller device classes have been implemented correctly. These devices reside on either the motherboard or add-in cards and may be integrated with the core chipset.

The PCICAP test accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode (also known as Command Mode), including PCI Read Configuration (Byte, Word, and Double Word) and PCI Write Configuration (Byte, Word, and Double Word). Additionally, the test invokes the following BIOS functions: Find BIOS Present and Find PCI Device.

Algorithm

As directed, PCICAP performs the following steps:

  1. Scans the system to build a linked list of all PCI devices and gathers available information about the configuration header and the new capability list for all PCI devices.
  2. Locates all devices in PCI bus 0.
  3. Does the following for the previously mentioned device classes:
    1. Determines whether it supports any new capabilities,
    2. Locates all functions that this device implements,
    3. For each PCI function with power management capability, PCICAP verifies that the system has correctly implemented its new power management capability register.
  4. Repeats steps 2 and 3 for devices in all remaining PCI buses.

Subsystem Device ID and Subsystem Vendor ID Test (PCISID)


Type Manual
Operating system Pre OS (Command Mode)
Log filename pcisid.log
Status Preview: Not Required
Included in these HCTs: 9.x

The purpose of the PCI Subsystem Device ID and Subsystem Vendor ID (PCISID) test is to verify correct implementation of the subsystem IDs, as specified in the PC 99 System Design Guide. The PCISID test accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode.

Algorithm

As directed, PCISID performs the following steps:

  1. Scans the system to build a linked list of all PCI devices and gathers available information about the configuration header and the new capability list for all PCI devices.
  2. Locates all devices in PCI bus 0
  3. Does the following for each of the device classes, except the core chipsets and PCI-to-PCI bridges:
    1. Determines whether the system has implemented the PCI Subsystem Device ID (SID) and Subsystem Vendor ID (SVID).
    2. Determines whether both the SID and SVID values are nonzero and legal.
    3. Determines whether both the SID and SVID values are not directly writable.
    4. Does the following to verify that both the SID and SVID values are not lost after transitioning the system to S3 Sleep state:
      1. Saves the current values of both the SID and SVID,
      2. Enters ACPI mode and installs the SCI handler,
      3. Programs the Power Button Event to awaken the system,
      4. Transitions the system to the S3 state via ACPI mode,
      5. When the Power Button Event awakens the system, the test retrieves the current values of both the SID and SVID,
      6. Compares the original values of the SID and SVID with the current ones,
      7. If the test determines that a mismatch exists, it generates an error report,
      8. Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.
  4. Repeats steps 2 and 3 for devices in all remaining PCI buses.

Power Management Diagnostic(s) Test (PMDIAG)


Type Manual
Operating system Pre OS (Command Mode)
Log filename PMDIAG.log
Status Required
Included in these HCTs: 9.x

The purpose of the Power Management Diagnostic(s) (PMDIAG) test is to verify the functional behavior of the PCI test adapter for the combinations of the PCI bus power state, B0, and the function power states, D0, D1, D2, D3 Hot, and D3 Cold. This test is also intended to verify all possible function power state transitions from each function's power state.

PMDIAG accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode, including PCI Read Configuration Byte, Word, and Double Word and PCI Write Configuration Byte, Word, and Double Word. Additionally, the test invokes the BIOS functions, Find BIOS Present and Find PCI Device.

The test writes an appropriate value to the PowerState field in the PMCSR Register to set the PCI function being evaluated to a new power state. Successfully running this test requires the use of the special Foxfire II PCI test adapter.

Algorithm

As directed, PMDIAG performs the following steps:

  1. Determines whether the PCI bus 0 is in B0 state.
  2. Determines whether the PCI test adapter is in Uninitialized D0 state.
  3. Identifies the PCI configuration space of the installed PCI test adapter.
  4. Performs multiple PCI configuration cycles for each PCI test adapter function.
  5. Verifies access to the PCI configuration space.
  6. Initializes the installed PCI test adapter and transitions its function power state to D0 Active.
  7. Verifies the power management register functionality of the PCI test adapter.
  8. For each of the PCI test adapter's function power states, D0 Active, D1, D2, and D3 Hot, PMDIAG does the following:
    1. Performs PCI configuration cycles.
    2. Verifies access to the PCI configuration space.
    3. Verifies every possible transition from each function's power states.
  9. Verifies the functionality of the PCI test adapter's specific registers, e.g. Misc_PMCTL Register.
  10. Repeats the preceding steps after installing the PCI test adapter in each remaining PCI slot.
  11. If a PCI-to-PCI bridge exists, PMDIAG repeats the preceding steps after installing the PCI test adapter behind this bridge.

PME Signal Routing Test (PCIPME1)


Type Manual
Operating system Pre OS (Command Mode)
Log filename pcipme1.log
Status Preview: Not Required
Included in these HCTs: 9.x

The purpose of the PME# Signal Routing (PCIPME1) test is to verify that the PCI system hardware correctly sequences between the various system sleep states and working states in response to the PME# signal assertion from the PCI test adapter (Foxfire II card). This enables the test to validate whether each PME# signal assertion tested invokes a service routine.

Algorithm

As directed, PCIPME1 performs the following steps:

  1. Identifies the PCI configuration space of the installed PCI test adapter. The PCI test adapter must be in Uninitialized D0 state.
  2. Initializes the PCI test adapter and transitions its power state to D0 Active.
  3. Locates ACPI tables and identifies the SCI vector.
  4. Disables all known ACPI event interruption sources.
  5. Installs the SCI handler and transitions the system to ACPI mode.
  6. Sets the value in the PCI test adapter's LoadSelect field (bits 1-2) in its Misc_PMCTL Register to 160mA.
  7. Transitions the PCI test adapter to D3 Hot state.
  8. Clears the PME_Status bit.
  9. Sets the PME_En bit to a value of 1.
  10. Executes the _PRW object for Root PCI Bus device.
  11. Determines which General Purpose Event (GPE) Register bit is dedicated to PME# signal generation.
  12. Determines the lowest power-sleep state allowed.
  13. Clears all status bits in each GPE Register.
  14. Clears all ACPI chipset status bits.
  15. Sets the GPE register enable bit.
  16. Resets the SCI count for the general-purpose event.
  17. Instructs the user to do the following:
  18. Press any key to enter the Sx (where x > 1) Sleep state.
  19. Press the PCI test adapter's PME# assertion button to awaken the system.
  • Places the system in the appropriate sleep state (Sx (where x > 1) Sleep)
  • When the system awakens from the sleep state, check the SCI count.
  • Determines who asserted the PME# signal.
  • Clears the PME_Status bit.
  • Clears the PME_En bit.
  • Sets the PCI test adapter to D1 Active state via its PowerState field.
  • Verifies the GPE status bit.
  • Clears the GPE status bit.
  • Clears the GPE enable bit.
  • Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.

    Multiple PME Assertion Test (PCIPME2)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename PCIPME2.log
    Status Not Required: Preview
    Included in these HCTs: 9.x

    The purpose of the Multiple PME# Assertion (PCIPME2) test is to verify that the PCI system hardware simultaneously sequences between the various system sleep states and working states in response to the PME# signal assertions from multiple PCI test adapters (Foxfire II Cards).

    This test is functionally the same as the PME Signal Routing Test (PCIPME1), except that multiple test adapters are used. Successfully running this test requires the use of multiple special Foxfire II PCI test adapters.

    Algorithm

    Same as for the PME Signal Routing Test (PCIPME1).

    3.3Vaux Auxiliary Power Test (PCIVAUX)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename PCIVAUX.log
    Status Preview: Not Required
    Included in these HCTs: 9.x

    The purpose of the 3.3Vaux Auxiliary Power (PCIVAUX) test is to verify whether systems that support 3.3Vaux power are capable of fully powering at least one 3.3Vaux-enabled PCI slot while the PCI bus is in B3 state. The purpose of this test is also to verify whether such systems are capable of powering all slots in the system when the PCI bus is in B0, B1, or B2 state..PCIVAUX accesses PCI configuration space via the PCI run-time functions in Real Mode.

    Algorithm

    As directed, PCIVAUX performs the following steps:

    1. Identifies the PCI configuration of the first installed PCI test adapter.
    2. Initializes the PCI test adapter and transitions its power state to D0 Active.
    3. Reboots the system and performs the preceding two steps for the remaining test adapters.
    4. Determines the auxiliary current requirements for all PCI test adapters.
    5. For each PCI test adapter Sleep state, D0 Active, D1, D2, and D3 Hot; each auxiliary current setting, 375mA, 160mA, and 20mA; and each combination of PME_En bit, whether enabled or disabled, PCIVAUX:
      1. Programs each PCI test adapter to generate the PME# signal(s) immediately.
      2. Determines whether the system generated the PME# event and compares the event with the expected result.
      3. Logs each failure that results.
    6. Locates ACPI tables and identifies the SCI vector.
    7. Disables all known ACPI event interruption sources.
    8. Installs the SCI handler and transitions to ACPI mode.
    9. For each supported Sleep state, S1, S2, and S3; each PCI test adapter low-power state, D1, D2, D3 Hot, and D3 Cold; each auxiliary current setting, 375mA, 160mA, and 20mA; and each combination of PME_En bit, whether enabled or disabled, PCIVAUX:
      1. Clears all general-purpose event status and enabling bits.
      2. Programs each PCI test adapter to generate the PME# signal(s) following the next four steps.
      3. Satisfies all operating system requirements for the supported Sleep state.
      4. Writes the SLP_TYP register with the value specified in the \_Sx package.
      5. Executes the _PTS Prepare The Sleep control method.
      6. Sequences the hardware into the specified sleeping state.
      7. Executes the _WAK control method.
      8. When the PME-enabled event awakens the system, PCIVAUX verifies that the status bit of the wake event is active..
      9. Determines whether the system generated the PME# event and compares the event with the expected result.
      10. Logs each failure that results.
    10. Clears all general-purpose event status and enabling bits.
    11. Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.

    Device Wake-Up (PCIWAKE)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename PCIWAKE.log
    Status Required
    Included in these HCTs: 9.x

    The purpose of the Device Wake-Up (PCIWAKE) test is to verify the PCI function's awakening behavior for the PCI bus with the S0 system state. The PCI function must support the assertion of the PME# signal that indicates the awakening event.

    Algorithm

    As directed, PCIWAKE performs the following steps:

    1. Identifies the PCI configuration space of the installed PCI test adapter. The PCI test adapter must be in Uninitialized D0 state.
    2. Initializes the PCI test adapter and transitions its power state to D0 Active.
    3. Locates ACPI tables and identifies the SCI vector.
    4. Disables all known ACPI event interruption sources.
    5. Installs the SCI handler and transitions the system to ACPI mode.
    6. For the S0 sleep state, each PCI test adapter power state, D1, D2, D3 Hot, and D3 Cold; and each combination of PME_En bit, whether enabled or disabled, PCIWAKE:
      1. Clears all general-purpose event status and enabling bits.
      2. Saves the test adapter function's context.
      3. Programs the test adapter for generating the PME# signal following the next four steps.
      4. Satisfies all operating system requirements for the supported Sleep state.
      5. Writes the SLP_TYP register with the value specified in the \_Sx package.
      6. Executes the _PTS Prepare The Sleep control method.
      7. Sequences the hardware into the specified Sleep state
      8. Executes the _WAK control method.
      9. When the PME-enabled event awakens the system, the PCI test adapter's function must be in Uninitialized D0 state, the PCI bus in B0 state, and the system in S0 Working state.
      10. Verifies the status bit of the awakening event.
      11. Restores the test adapter function to the original context.
    7. Clears all general-purpose event status and enabling bits.
    8. Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.
    9. Repeats the preceding steps after installing the test adapter in each of the remaining PCI slots.
    10. If a PCI-to-PCI bridge exists, PCIWAKE repeats the preceding steps after installing the test adapter behind the bridge

    Device Wake-Up (All States)(PCIWAKEA)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename PCIWAKEA.log
    Status Preview: Not Required
    Included in these HCTs: HCT 9.2 Beta 2 Web Update, 9.5

    The purpose of the Device Wake-Up (PCIWAKEA) test is to verify the PCI function's awakening behavior for various combinations of bus and function power states, including S1-S3. The PCI function must support the assertion of the PME# signal that indicates the awakening event.

    Algorithm

    As directed, PCIWAKEA performs the following steps:

    1. Identifies the PCI configuration space of the installed PCI test adapter. The PCI test adapter must be in Uninitialized D0 state.
    2. Initializes the PCI test adapter and transitions its power state to D0 Active.
    3. Locates ACPI tables and identifies the SCI vector.
    4. Disables all known ACPI event interruption sources.
    5. Installs the SCI handler and transitions the system to ACPI mode.
    6. For each supported Sleep state, S1, S2, and S3; each PCI test adapter power state, D1, D2, D3 Hot, and D3 Cold; and each combination of PME_En bit, whether enabled or disabled, PCIWAKEA:
      1. Clears all general-purpose event status and enabling bits.
      2. Saves the test adapter function's context.
      3. Programs the test adapter for generating the PME# signal following the next four steps.
      4. Satisfies all operating system requirements for the supported Sleep state.
      5. Writes the SLP_TYP register with the value specified in the \_Sx package.
      6. Executes the _PTS Prepare The Sleep control method.
      7. Sequences the hardware into the specified Sleep state
      8. Executes the _WAK control method.
      9. When the PME-enabled event awakens the system, the PCI test adapter's function must be in Uninitialized D0 state, the PCI bus in B0 state, and the system in S0 Working state.
      10. Verifies the status bit of the awakening event.
      11. Restores the test adapter function to the original context.
    7. Clears all general-purpose event status and enabling bits.
    8. Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.
    9. Repeats the preceding steps after installing the test adapter in each of the remaining PCI slots.
    10. If a PCI-to-PCI bridge exists, PCIWAKE repeats the preceding steps after installing the test adapter behind the bridge

    PCI Voltage Requirement Test (PCIVOLT)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename pcivolt.log
    Status Required
    Included in these HCTs: 9.x

    The purpose of the PCI Voltage Requirement (PCIVOLT) test is to verify that PCI-based systems support the appropriate voltages to all PCI connectors. PCIVOLT accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode, including PCI Read Configuration Byte, Word, and Double Word and PCI Write Configuration Byte, Word, and Double Word.

    Algorithm

    PCIVOLT performs the following steps:

    1. Identifies the PCI configuration space of the installed PCI test adapter.
    2. Initializes the PCI test adapter and transitions its power state to D0 Active.
    3. Reads the PCI test adapter's Misc_PMCTL Register to determine the presence of a 3.3Vaux, 3.3V, and/or 5V power supply. If any of these PCI voltages is not detected, PCIVOLT reports an error. It also verifies that the appropriate LEDs on the back-panel bracket of the PCI test adapter are lit for each PCI voltage detected.
    4. Programs the PCI test adapter's power state to D3 Hot.
    5. Transitions the system to S1 system power state (S0-S1), then awakens the system using PME# signal assertion (S1-S0). During these system power transitions, PCIVOLT measures the 3.3Vaux voltage using a voltmeter. The DC operating voltage band for a 3.3Vaux-enabled system must range from 3.0V-3.6V; otherwise, PCIVOLT reports an error.
    6. Programs the PCI test adapter's power state to D0.
    7. Repeats the preceding three steps with S3 system power state instead of S1.
    8. Repeats steps 1 through 6 after installing the PCI test adapter in each remaining PCI slot.

    BIOSINIT


    Type Manual
    Operating system Pre OS (Command Mode)
    Processing time
    Log filename biosinit.log
    Status Preview: Not Required
    Included in these HCTs: 9.x

    The purpose of the System BIOS Initialization Requirement (BIOSINIT) test is to verify that the system BIOS masks off the PME# signal during the system power-on sequence. BIOSINIT accesses PCI configuration space via the PCI run-time functions in Real Mode.

    Algorithm

    BIOSINIT performs the following steps:

    1. Initializes the PCI test adapter and transitions its power state to D0 Active.
    2. Identifies the PCI configuration space of the installed PCI test adapter.
    3. Reads the PCI test adapter's PMCSR Register to determine the current bit settings for both PME_Status and PME_En. If BIOSINIT does not read the PME_Status bit as value 0b and the PME_En bit as value 1b, BIOSINIT reports an error.
    4. Determines whether the PCI test adapter's power state is D0. If its state is not D0, BIOSINIT reports an error.
    5. Repeats the preceding steps during the system power-on sequence.

    BIOSINITZ


    Type Manual
    Operating system Pre OS (Command Mode)
    Processing time
    Log filename biosinitz.log
    Status Preview: Not Required
    Included in these HCTs: HCT 9.2 Beta 2 Web Update, 9.5

    The purpose of the System BIOS Initialization Requirement (BIOSINITZ) test is to verify that the system BIOS masks off the PME# signal during the system warm-boot ([Control+Alt+Del]) sequence. BIOSINITZ accesses PCI configuration space via the PCI run-time functions in Real Mode.

    Algorithm

    BIOSINITZ performs the following steps:

    1. Initializes the PCI test adapter and transitions its power state to D0 Active.
    2. Identifies the PCI configuration space of the installed PCI test adapter.
    3. Reads the PCI test adapter's PMCSR Register to determine the current bit settings for both PME_Status and PME_En. If BIOSINITZ does not read the PME_Status bit as value 0b and the PME_En bit as value 1b, BIOSINITZ reports an error.
    4. Determines whether the PCI test adapter's power state is D0. If its state is not D0, BIOSINITZ reports an error.
    5. Repeats the preceding steps during the system warm-boot ([Control+Alt+Del]) sequence.

    Pre OS ACPI Tests

    ACPI Table and Name Space Dump (ACPIDUMP)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename ACPIDump.log
    Status Required
    Included in these HCTs: 9.x

    The ACPI name space dump (ACPIDUMP) test suite verifies the ACPI tables and name space. ACPIDUMP verifies implementation of the minimum ACPI BIOS support assertions by the target platform.

    Algorithm

    ACPIDUMP performs the following steps:

    1. Locate and display all tables, validating checksums for all table checksums.
    2. For the DSDT, perform the following name space validate.
    3. Verify each reserved name (name beginning with "_") is defined by the ACPI specification.
    4. Verify all names are unique at their scope level.
    5. Verify each name has a definition block.
    6. Verify internal checksums for objects with checksums.
    7. Verify minimal length values.
    8. Verify register alignment values.
    9. Verify required control methods and registers.

    If this test reports a failure, see Section 16 of the Advanced Configuration and Power Interface Specification, Revision 1.0(a) for the current ACPI Machine Language (AML) Specification, including the AML grammar definition and AML byte stream byte values. The test reports as much context as possible surrounding the failure and resort to a hex dump of the values within the ACPI name space that are undecipherable due to errors. The display re-synchronizes on the next root-level ACPI name space control method.

    ACPI Device Power Management (ACPIDPMT)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename acpidpmt.log
    Status Required
    Included in these HCTs: 9.x

    The ACPI device power management (ACPIDPMT) test suite verifies correctness of all device power management operations that can be performed on each device defined by the ACPI name space: device related hardware registers, Dx device power state transitions, and ACPI name space support.

    Note: ACPIPBT and ACPIDPMT may cause memory allocation errors on some systems. If this happens and the system hangs, cold boot the system with floppy disk 1 in drive. This should restart the test suite with the next test.

    Algorithm

    ACPIDPMT performs the following steps:

    1. Locate the ACPI tables and identify the SCI vector.
    2. Disable all known ACPI event interrupt sources.
    3. Install the system control interrupt handler and transition system to ACPI mode.
    4. Enumerate all motherboard devices in the ACPI name space using _ADR, _HID, _STA, _CRS, and _PRS control methods.
    5. Determine if the system has a _PSR control method. If the method exists, execute it and display whether the AC adapter is on-line or off-line.
    6. Determine if the system has a _PCL control method. If themethod exists, execute it and display the devices powered by this power source.
    7. Determine if the system has a _ON control methods. If any _ON methods exist, list the devices that support each _ON method.
    8. Determine if the system has a _OFF control methods. If any _OFF methods exist, list the devices that support each _OFF method.
    9. Select first / next enumerated device.
      1. Display each device's power resource requirements for each state (D0-D2) by executing the _PR0, _PR1, and _PR2 control methods if they exist.
      2. Determine if the _IRC control method exists for the current device. If so, this device has an inrush current when transitioning to the D0 state that requires serialization with other devices with inrush currents.
      3. Obtain and save the state of the current device via _CRS, _PSC, and _STA control methods. If _PSC does not exist, verify _PR1, _PR2, and _PR3 do not exist.
      4. Verify the current state, if possible, by directly examining the device hardware registers.
      5. Identify all child devices, save their state, and transition them to the D3 off device power state.
      6. For each device where _CRS, _PSC, and _PSx (x=1,...., 3) exist.
    10. Restore all devices to their original device power state and verify using the _PSC and _STA control methods and, if possible, by directly esamining the devcie hardware registers.
    11. Return to legacy (non-ACPI) mode and uninstall SCI handler.

    Legacy / ACPI State Transition (ACPILAST)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename ACPILAST.log
    Status Required
    Included in these HCTs: 9.x

    The legacy / ACPI state transition (ACPILAST) test suite verifies the hardware correctly sequences between the legacy (non-ACPI) and ACPI modes. While other test cases perform this sequence, ACPILAST focuses on these transitions and makes the transition n times before declaring success.

    Algorithm

    ACPILAST performs the following steps

    1. Locate the ACPI tables and identify the SCI vector.
    2. Disable all known ACPI event interrupt sources.
    3. Install the system control interrupt handler and transition system to ACPI mode.
    4. Enable power management timer (PMT) event.
    5. If the system is an ACPI-only system, skip to step 8.
    6. Validate legacy (non-ACPI) mode to legacy mode transitions (repeat n iterations).
      1. Transition system to legacy (non-ACPI) mode.
      2. Verify the system is in legacy (non-ACPI) mode by verifying SCI_EN is low.
      3. Wait for PMT roll-over and ensure that no system control interrupt occurs.
    7. Validate legacy (non-ACPI) mode to ACPI mode transition and ACPI mode to legacy (non-ACPI) mode transition. (repeat n iterations).
      1. Transition system to legacy (non-ACPI) mode.
      2. Verify system is in legacy (non-ACPI) mode by verifying SCI_EN is low.
      3. Wait for PMT roll-over and ensure that no system control interrupt occurs.
      4. Transition system to ACPI mode.
      5. Verify that the system is in ACPI mode by verifying that SCI_EN is high.
      6. Wait for PMT roll-over and ensure that system control interrupt does occur.
    8. Validate ACPI mode to ACPI mode transitions.
      1. Transition system to ACPI mode.
      2. Verify that the system is in ACPI mode by verifying that SCI_EN is high.
    9. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

    ACPI Power Button and Sleep Button (ACPIPBT)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename ACPIPBT.log
    Status Required
    Included in these HCTs: 9.x

    The ACPI power button and sleep button (ACPIPBT) test suite verifies the functionality of the ACPI power and/or sleep buttons. See "ACPI Power Button and Sleep Button Assertions"(link). With the exception of testing the power button over-ride feature, this test does not verify sleep state transitions initiated by the power button and sleep button.

    Note: ACPIPBT and ACPIDPMT may cause memory allocation errors on some systems. If this happens and the system hangs, cold boot the system with floppy disk 1 in drive. This should restart the test suite with the next test.

    Algorithm

    ACPIPBT performs the following steps:

    1. Locate ACPI tables and identify SCI vector and location of the power button status and enable bits.
    2. Disable all known ACPI event interrupt sources.
    3. Install the system control interrupt handler and transition system to ACPI mode.
    4. If the power button is a fixed feature:
      1. Clear power button status bit (PWRBTN_STS) and power button enable bit (PWRBTN_EN).
      2. Verify PWRBTN_STS is set and SCI is not generated when power button is pressed.
      3. Clear power button status bit (PWRBTN_STS) and set (enable) power button enable bit (PWRBTN_EN).
      4. Verify PWRBTN_STS is set and SCI is generated when power button is pressed.
    5. If the sleep button is implemented as a fixed feature.
      1. Clear sleep button status bit and sleep button enable bit.
      2. Verify sleep button status is set and SCI is not generated when sleep button is pressed.
      3. Clear sleep button status bit and set (enable) sleep button enable bit.
      4. Verify sleep button status is set and SCI is generated when sleep button is pressed.
      5. Clear sleep button status bit and sleep button enable bit.
    6. If the power button is a fixed feature, verify it can wake the system for each supported sleep state Sx (S1-S4BIOS, S4 not tested).
      1. Set the power button enable bit and clear the status bit.
      2. Put the system in the Sx supported sleep state.
      3. User presses power button to wake system.
      4. Clear the power button enable bit and clear the status bit.
      5. Put the system in the Sx supported sleep state.
      6. User presses power button to wake system.
    7. Verify power button over-ride. (This section may be separated into a unique test executable.)
      1. Clear power button status bit (PWRBTN_STS) and set (enable) power button enable bit (PWRBTN_EN).
      2. Flush caches and close files.
      3. Prompt user to press and hold power button.
      4. When PWRBTN_STS is set (SCI occurs), start a timer, writing timer tick to two (alternating) files.
      5. If timer exceeds 4.25 seconds, fail power button over-rides.
      6. If system powers down as expected, reboot and inspect log files. If the system shuts down before 3.75 seconds, use fail power button over-ride.
    8. If system did not power down as expected, transition system to legacy (non-ACPI) mode and uninstall system control interrupt handler.

    ACPI Power Management Timer (ACPIPMT)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename acpipmt.log
    Status Required
    Included in these HCTs: 9.x

    The ACPI power management timer (ACPIPMT) test suite verifies the power management timer (PMT) related hardware registers and events.

    ACPI Processor Throttling (CPUTHRTL)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename cputhrtl.log
    Status Required
    Included in these HCTs: 9.x

    The ACPI processor throttling (CPUTHRTL) test suite verifies CPU throttling support.

    Algorithm

    CPUTHTRL performs the following steps:

    1. Locate ACPI tables and identify system control interrupt vector.
    2. Verify the ACPI name space supports processor throttling. If not supported, exit test.
    3. Disable all known ACPI event interrupt sources.
    4. Install system control interrupt handler and transition the system to ACPI mode.
    5. Measure the time required to perform a specific task.
    6. Enable processor throttling.
    7. Measure the time required to perform the same task.
    8. Return the processor to full speed.
    9. Compare the execution times to determine pass/fail status.
    10. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

    Interrupt 15h Function E820h (I15E820)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename I15E820.log
    Status Required
    Included in these HCTs: 9.x

    The ACPI interrupt 15h function E820h query system address map (I15_E820) test suite verifies the BIOS interrupt 15h function E820h.

    Algorithm

    15_E820 performs the following steps:

    1. Obtain addresses of all ACPI tables.
    2. Verify presence of interrupt 15h function E820h.
    3. Execute interrupt 15h function E820h.
    4. Verify all memory claimed by ACPI tables outside of F000h BIOS block other than the RSDP and RSDT is included in the ACPI reclaim memory.
    5. Verify that interrupt 15h function DA88h (if supported) and interrupt 15h function E801h return memory size that agrees with the memory size returned by the interrupt 15h function E820h.
    6. Verify memory ranges defined do not overlap.
    7. Verify that ACPI tables are properly defined in AddressRange and AddressRangeNVS memory ranges.
    8. Verify that interrupt 15h function E820h returns carry flag set if called with an invalid signature value of 0FFFFFFFFh.
    9. Verify that interrupt 15h function E820h returns carry flag set if called with an invalid continuation value of 0FFFFh.

    ACPI Power Button 4 Second Override (Acpi4Sec)


    Type Manual
    Operating system Pre OS (Command Mode)
    Log filename Acpi4Sec.log
    Status Required
    Included in these HCTs: 9.x

    The purpose of the ACPI power button 4 second override test is to verify that the ACPI power button can power down the system within four seconds. If the system powers down when the power button is heild for four seconds, the ACPI4SEC test passes.