3.2.1. session_open_event(+)

Purpose:

Retrieve the same events from two sessions which are associated to the same domain

Procedure:

• Step1 open two sessions with the same domain using saHpiSessionOpen

• Step2 subscribe for events to two sessions using saHpiSubscribe

• Step3+ manually generate an event

• Step4 retrieve events using saHpiEventGet

Expected Behavior:

Two Events retrieved from two sessions are equal

Statements:

Refer to 3.1 Sessions in HPI specification A.01.01

3.2.2. saHpiSessionOpen_T1

Purpose:

Retrieve the same RPT information from two sessions which are associated to the same domain

Condition:

No resource is inserted into or removed from system during testing

Procedure:

• Step1 open two sessions with the same domain using saHpiSessionOpen

• Step2 saHpiResourcesDiscover

• Step3 retrieve RPT information from two sessions using saHpiRptInfoGet

Expected Behavior:

Two entries of RPT information which are retrieved from two sessions are equal

Statements:

Refer to 3.1 Sessions in HPI specification A.01.01

3.2.3. saHpiSessionClose_T1

Purpose:

Verify whether the session is closed after calling saHpiSessionClose

Procedure:

• Step1 saHpiSeesionOpen

• Step2 saHpiSessionClose

• Step3 saHpiResourcesDiscover

Expected Behavior:

saHpiResourceDisover returns error code

Statements:

Refer to 5.1.2 saHpiSessionClose() in HPI specification A.01.01

Comments:

After closing a session, the session ID will no longer be valid

3.2.4. resource_discover_static(*)

Purpose:

Discover the resources after initializing the system

Condition:

No resource is inserted into and removed from system

Procedure:

• Step1 saHpiResourcesDiscover

• Step2 list all RPT entries

• Step3* manually check the RPT entries listed

Expected Behavior:

All RPT entries listed in step2 accords with the existing entries in system

Statements:

Refer to 5.2.1 saHpiResourcesDiscover() in HPI specification A.01.01

3.2.5. resource_discover_remove(*)

Purpose:

Discover the resources after removing a resource

Procedure:

• Step1 saHpiResourcesDiscover

• Step2* manually remove a resource from system

• Step3 saHpiResourcesDiscover

• Step4 list all RPT entries

• Step5* manually check the RPT entries listed

Expected Behavior:

All RPT entries listed accords with the existing entries in system after removing a resource. That is to say, the resource which is removed from system is not included in the RPT entries listed

Statements:

Refer to 5.2.1 saHpiResourcesDiscover() in HPI specification A.01.01

3.2.6. resource_discover_insert(*)

Purpose:

Procedure:

• Step1 saHpiResourcesDiscover

• Step2* manually insert a resource into system

• Step3 saHpiResourcesDiscover

• Step4 list all RPT entries

• Step5* manually check the RPT entries listed

Expected Behavior:

All RPT entries listed accords with the existing entries in system after inserting a resource. That is to say, the resource which is inserted into system is included in the RPT entries listed

Statements:

Refer to 5.2.1 saHpiResourcesDiscover in HPI specification A.01.01

3.2.7. saHpiRptInfoGet_T1

Purpose:

Verify the RPT information is correct

Procedure:

• Step1 saHpiResourcesDiscover

• Step2 retrieve RPT information using saHpiRptInfoGet

• Step3 sleep for a short time

• Step4 saHpiResourcesDiscover

• Step5 retrieve RPT information using saHpiRptInfoGet

Expected Behavior:

The RPT information is correctly updated. Please to refer to 7.18 Resource Presence Table which specifies how to update RPT information

Statements:

Refer to 5.2.1 saHpiResourcesDiscover(), 5.2.2 saHpiRptInfoGet() and 7.18 Resource Presence Table in HPI specification A.01.01

Comments:

After calling saHpiResourcesDiscover, the RPT table and RPT information is updated.

3.2.8. saHpiRptEntryGetByResourceId_T1

Purpose:

Verify the RPT entry retrieved by resource ID

Procedure:

Retrieve all the rpt entries using saHpiRptInfoGet. For each RPT entry, the followings step is done:

• Step1 retrieve the resource ID from the RPT entry

• Step2 retrieve the RPT entry using saHpiRptEntryGetByResourceId and the resource ID

• Step3 compare the original RPT entry and the retrieved RPT entry

Expected Behavior:

The original RPT entry is equal to the retrieved RPT entry

Statements:

Refer to 5.2.4 saHpiRptEntryGetByResourceId() and 7.18 Resource Presence Table in HPI specification A.01.01

3.2.9. resource_severity_set(*)

Purpose:

Set events' severity level

Procedure:

• Step1 saHpiResourceSeveritySet

• Step2* manually make a resource unexpectedly become unavailable to the HPI

• Step3 saHpiEventGet

Expected Behavior:

The event's severity level is equal to the level which is set in step 1

Statements:

Refer to 5.2.5 saHpiResourceSeveritySet() in HPI specification A.01.01

Comments:

saHpiResourceSeveritySet sets the severity level applied to an event issued if a resource unexpected unavailable to the HPI

3.2.10. saHpiResourceTagSet_T1

Purpose:

Set a tag for a particular resource

Procedure:

• Step1 saHpiResourceTagSet

• Step2 saHpiRptInfoGet

• Step3 retrieve the resource tag from the RPT entry

Expected Behavior:

The tag which is set in step1 is equal to the tag which is retrieved in step3

Statements:

Refer to 5.2.6 saHpiResourceTagSet() in HPI specification A.01.01

Comments:

saHpiResourceTagSet sets the resource tag for a particular resource. The resource tag is an informational value that supplies the caller with naming information for the resource

3.2.11. saHpiEntitySchemaGet_T1

Purpose:

Get the same schema identifier

Procedure:

• Step1 open all the domains

• Step2 open two sessions for each domain

• Step3 saHpiEntitySchemaGet

Expected Behavior:

All schema IDs are equal

Statements:

Refer to 5.2.8 saHpiEntitySchemaGet() in HPI specification A.01.01

Comments:

saHpiEntitySchemaGet may be issued on any session opened to any domain in the system, and will return the same identifier

3.2.12. saHpiEntitySchemaGet_T2

Purpose:

Check the value of the schema

Procedure:

• Step1 open session for default domain

• Step2 saHpiEntitySchemaGet

Expected Behavior:

The identifier value may be zero, ('C'<<24)|('P'<<16)|('C'<<8)|'I', or ('A'<<24)|('T'<<16)|('C'<<8)|'A',('O'<<24)|('E'<<16)|('M'<<8)|'0'-'F'. Other value is not allowed

Statements:

Refer to 5.2.8 saHpiEntitySchemaGet() and A. Pre-Defined Entity Schemas in HPI specification A.01.01

Comments:

The identifier returned is either zero or one of the Pre-defined schema identifiers

3.2.13. saHpiEventLogTimeGet_Set_T1

Purpose:

Verify whether the time clock of the system event log can work

Procedure:

• Step1 saHpiEventLogTimeSet

• Step2 sleep for a short time

• Step3 saHpiEventLogTimeGet

Expected Behavior:

The retrieved time minus the set time approximates sleep time

Statements:

Refer to 5.3.6 saHpiEventLogTimeGet() and 5.3.7 saHpiEventLogTimeSet() in HPI specification A.01.01

Comments:

Each system event log has its own time clock, which is used for setting timestamps on log entries to that event log. The functions saHpiEventLogTimeGet and saHpiEventLogTimeSet are provided to allow an individual event log's clock to be read and set respectively

3.2.14. saHpiEventLogEntryAdd_T1

Purpose:

Add event into the system event log

Procedure:

• Step1 construct an event

• Step2 disable the event log using saHpiEventLogStateSet(SAHPI_FALSE)

• Step3 saHpiEventLogEntryAdd

• Step4 retrieve the newest event log entry

Expected Behavior:

The event retrieved from event log is equal to the constructed event

Statements:

Refer to 5.3.2 saHpiEventLogEntryGet(), 5.3.3 saHpiEventLogEntryAdd() and 5.3.9 saHpiEventLogStateSet() in HPI specification A.01.01

Comments:

If the event log is disabled, no events will be automatically added to the event log. But events may be added to the event log using the saHpiEventLogEntryAdd() function

3.2.15. saHpiEventLogInfoGet_T1

Purpose:

Retrieve log information

Procedure:

• Step1 enable the event log using saHpiEventLogStateSet

• Step2 retrieve log information using saHpiEventLogInfoGet

• Step3 disable the event log using saHpiEventLogStateSet

• Step5 construct an event and add it into the system event log

• Step6 retrieve log information using saHpiEventLogInfoGet

• Step7 retrieve the event log time using saHpiEventLogTimeGet

Expected Behavior:

• In step2, the event log state is equal to SAHPI_TRUE

• The event entry number is incremented by 1

• In step6, the event log state is equal to SAHPI_FALSE

• The overflow flag is equal to SAHPI_FALSE if the entry number is less than the total size

• The update time approximates to the event log time using saHpiEventLogTimeGet

• The current time approximates to the event log time using saHpiEventLogTimeGet

Statements:

Refer to 5.3.1 saHpiEventLogInfoGet(), 7.19 System Event Log in HPI specification A.01.01

3.2.16. saHpiEventLogClear_T1

Purpose:

Verify whether the contents of the system event log is erased

Procedure:

• Step1 disable the event log

• Step2 add more than 2 constructed events to event log using saHpiEventLogEntryAdd

• Step3 erase event log using saHpiEventLogClear

• Step4 retrieve the oldest event entry from event log using saHpiEventLogEntryGet

• Step5 add one event into event log using saHpiEventLogEntryAdd

• Step6 retrieve the oldest event entry from event log using saHpiEventLogEntryGet

Expected Behavior:

• In step4, the function returns error code

• In step6, the event retrived is equal to the event added. And no more entry can be retrieved from event log

Statements:

Refer to 5.3.5 saHpiEventLogClear()in HPI specification A.01.01

Comments:

saHpiEventLogClear function erases the contents of the specified system event log. In step4, the saHpiEventLogEntryGet function returns error code if the event log is erased.

3.2.17. saHpiEventLogEntryGet_T1

Purpose:

Retrieve the newest event log

Procedure:

• Step1 disable the event log

• Step2 erase event log using saHpiEventLogClear

• Step3 add the first contructed event to event log

• Step4 retrieve the newest event using saHpiEventLogEntryGet

• Step5 add the second contructed event to event log

• Step6 retrieve the newest event using saHpiEventLogEntryGet

Expected Behavior:

• In step4, next entry's id and previous entry's id are equal to SAHPI_NO_MORE_ENTRIES. The retrieved event is equal to the first constructed event.

• In step6, next entry's id is equal to SAHPI_NO_MORE_ENTRYIES and previous entry's id is not equal to SAHPI_NO_MORE_ENTY. The retrieved event is equal to the second constructed event.

Statements:

Refer to 5.3.2 saHpiEventLogEntryGet() in HPI specification A.01.01

3.2.18. saHpiEventLogEntryGet_T2

Purpose:

Retrieve the oldest event log

Procedure:

• Step1 disable the event log

• Step2 erase event log using saHpiEventLogClear

• Step3 add the first constructed event to event log using saHpiEventLogEntryAdd

• Step4 retrieve the oldest event using saHpiEventLogEntryGet

• Step5 add the second constructed event to event log using saHpiEventLogEntryAdd

• Step6 retrieve the oldest event using saHpiEventLogEntryGet

Expected Behavior:

• In step4, next entry's id and previous entry's id are SAHPI_NO_MORE_ENTRY. And the retrieved event is equal to the first constructed event.

• In step6, next entry's id is not equal to SAHPI_NO_MORE_ENTRY and previous entry's id is equal to SAHPI_NO_MORE_ENTRY. And the retrieved event is equal to the second constructed event.

Statements:

Refer to 5.3.2 saHpiEventLogEntryGet() in HPI specification A.01.01

3.2.19. event_log_state_set_disable(*)

Purpose:

Set event log into disable state

Procedure:

• Step1 saHpiEventLogStateSet(SAHPI_FALSE)

• Step2 saHpiEventLogClear

• Step3* manually make system to generate an event

• Step4 saHpiEventLogEntryGet(SAHPI_NEWEST_ENTRY)

Expected Behavior:

In step4, the function returns error code

Statements:

Refer to 5.3.9 saHpiEventLogStateSet() in HPI specification A.01.01

Comments:

The actual set of events that are automatically added to any event log is implementation-specific. Therefore, tester has to inquire which event belongs to the set before testing

3.2.20. event_log_state_set_enable(+)

Purpose:

Set event log into enable state

Procedure:

• Step1 saHpiEventLogStateSet(SAHPI_TRUE)

• Step2 saHpiEventLogClear

• Step3+ manually make system to generate an event

• Step4 saHpiEventGet

• Step5 saHpiEventLogEntryGet(SAHPI_NEWEST_ENTRY)

Expected Behavior:

The event retrieved in step4 is equal to the event retrieved in step5

Statements:

Refer to 5.3.9 saHpiEventLogStateSet() in HPI specification A.01.01

Comments:

The actual set of events that are automatically added to any event log is implementation-specific. Therefore, tester has to inquire which event belongs to the set before testing

3.2.21. saHpiEventLogStateGet_Set_T1

Purpose:

Retrieve event log state

Procedure:

• Step1 saHpiEventLogStateSet(SAHPI_TRUE)

• Step2 retrieve the event log state using saHpiEventLogStateGet

• Step3 saHpiEventLogStateSet(SAHPI_FALSE)

• Step4 retrieve the event log state using saHpiEventLogStateGet

Expected Behavior:

• In step 2, Enable is equal to SAHPI_TRUE

• In step 4 , Enable is equal to SAHPI_FALSE

Statements:

Refer to 5.3.8 saHpiEventLogStateGet in HPI specification A.01.01

Comments:

3.2.22. events_subsribe_alarm(*)

Purpose:

Subscribe for session events with providing active alarm

Procedure:

• Step1* change the external environment to make system have an active alarm

• Step2 saHpiSubscribe(SAHPI_TRUE)

• Step3 saHpiEventGet

• Step4* manually check the event retrieved in step3

Expected Behavior:

An event which reflects the sate of currently active alarms is retrieved

Statements:

Refer to 5.4 Events and 5.4.1 saHpiSubscribe()in HPI specification A.01.01

Comments:

The function saHpiSubscribe allows the caller to subscribe for session events. This single call provides subscription to all session events, regardless of event type or event severity. ProvideActiveAlarms Indicates whether or not alarms which are active at the time of subscription should be queued for future retrieval via the saHpiEventGet() function. In this case, ProvideActiveAlarms is ture

3.2.23. events_subsribe_noalarm(*)

Purpose:

Subscribe for session event without providing active alarm

Procedure:

• Step1* change the external environment to make system have an active alarm

• Step2 saHpiSubscribe(SAHPI_FALSE)

• Step3 saHpiEventGet

Expected Behavior:

No event which reflects the sate of currently active alarms is retrieved

Statements:

Refer to 5.4 Events and 5.4.1 saHpiSubscribe() in HPI specification A.01.01

3.2.24. events_subsribe_alarm(*)

Purpose:

Subscribe for session events with providing active alarm

Procedure:

• Step1* change the external environment to make system have an active alarm

• Step2 saHpiSubscribe(SAHPI_TRUE)

• Step3 saHpiEventGet

• Step4* manually check the event retrieved in step3

Expected Behavior:

Refer to 5.4 Events and 5.4.1 saHpiSubscribe()in HPI specification A.01.01

Statements:

The function saHpiSubscribe allows the caller to subscribe for session events. This single call provides subscription to all session events, regardless of event type or event severity. ProvideActiveAlarms Indicates whether or not alarms which are active at the time of subscription should be queued for future retrieval via the saHpiEventGet() function. In this case, ProvideActiveAlarms is ture

3.2.25. events_unsubscribe(+)

Purpose:

Verify whether the event queue is cleared after calling saHpiUnsubscribe

Procedure:

• Step1 saHpiSubscribe(SAHPI_FALSE)

• Step2+ manually generate an event

• Step3 saHpiUnsubscribe

• Step4 saHpiSubscribe(SAHPI_FALSE)

• Step5+ manually generate an event

• Step6 saHpiEventGet

Expected Behavior:

In step6, events which are subscribed before step4 aren't retrieved

Statements:

Refer to 5.4.2 saHpiUnsubscribe() in HPI specification A.01.01

3.2.26. saHpiEventGet_T2

Purpose:

Verify whether the function is non-blocking

Procedure:

• Step1 saHpiSubscribe(SAHPI_FALSE)

• Step2 retrieve current time

• Step3 saHpiEventGet(SAHPI_TIMEOUT_IMMEDIATE)

• Step4 retrieve current time

Expected Behavior:

saHpiEventGet returns SA_OK or SA_ERR_HPI_TIMEOUT. If the function returns SA_OK Event, RDR and RPT is inilialized. If the function returns SA_ERR_HPI_TIMEOUT, the time gap between step2 and step4 is very short.

Statements:

Refer to 5.4.3 saHpiEventGet() in HPI specification A.01.01

Comments:

The function saHpiEventGet has two way of calling function. One is non-blocking,in which the function immediately returns if there are no events available. The other is blocking, in which the function is blocked if there are no events available

The intention to check the time gap is verify whether the function returns immediately. Howerver, it is very difficult to decide whether the time gap is very short. It is assumed that a short time means the duraton within which 100000 pieces of add and multiply operation finish executing.

3.2.27. saHpiEventGet_T1

Purpose:

Verify whether the function is blocked if no event issues

Procedure:

• Step1 saHpiSubscribe(SAHPI_FALSE)

• Step2 saHpiEventGet(SAHPI_TIMEOUT_BLOCK)

Expected Behavior:

• If no event issues, the function is blocked. If an event issues, the function return SA_OK and event, RDR and RPT are initialized.

Statements:

Refer to 5.4.3 saHpiEventGet() in HPI specification A.01.01

Comments:

If no event is issued, the function is blocked forever. It is assumed that a specified time means forever.

3.2.28. saHpiEventGet_T3

Purpose:

Verify whether the function blocks for a time specified by the timeout paramete

Procedure:

• Step1 saHpiSubscribe(SAHPI_FALSE)

• Step2 retrieve the current time

• Step3 saHpiEventGet(timeout)

• Step4 retrieve the current time

Expected Behavior:

• If no event issues, the function returns SA_ERR_HPI_TIMEOUT and the time gap between step2 and step4 approximates the timeout specified by the function.

• If an event issues, the function return SA_OK and the event, RDR and RPT is initialized.

Statements:

Refer to 5.4.3 saHpiEventGet() in HPI specification A.01.01

3.2.29. resource_rdr_get(*)

Purpose:

Retrieve all RDRs from the specified resource

Procedure:

• Step1 list all RDRs using saHpiRdrGet

• Step2* manually check the RDRs

Expected Behavior:

All the RDRs listed accords with the existing resource

Statements:

Refer to 6.1.1 saHpiRdrGet() in HPI specification A.01.01

3.2.30. saHpiSensorReadingConvert_T2

Purpose:

Convert a raw sensor reading value to all interpreted values

Procedure:

• Step1 retrieve the sensor data format

• Step2 convert a raw sensor reading value to an interpreted value using saHpiSensorReadingConvert

Expected Behavior:

The value is correctly converted. Please refer to 7.5 Sensor Resource Data Records

Statements:

Refer to 6.2.2 saHpiSensorReadingConvert() and 7.5 Sensor Resource Data Records in HPI specification A.01.01

3.2.31. saHpiSensorReadingConvert_T1

Purpose:

Convert an interpreted sensor reading value to a raw value

Procedure:

• Step1 retrieve the sensor data format

• Step2 convert an interpreted sensor reading value to a raw value using saHpiSensorReadingConvert

Expected Behavior:

The value is correctly converted. Please refer to 7.5 Sensor Resource Data Records

Statements:

Refer to 6.2.2 saHpiSensorReadingConvert() and 7.5 Sensor Resource Data Records in HPI specification A.01.01

3.2.32. sensor_thresholds_set(*)

Purpose:

Set the thresholds for the given sensor

Procedure:

• Step1 set the thresholds for the given sensor

• Step2* manually change the environment for the given sensor

• Step3 retrieve events

Expected Behavior:

An event which reflects change of the environment is retrieved

Statements:

Refer to 6.2.4 saHpiSensorThresholdsSet()in HPI specification A.01.01

3.2.33. saHpiSensorThresholdsGet_Set_T1

Purpose:

Retrieve the thresholds for the given sensor

Procedure:

• Step1 saHpiSensorThresholdsSet

• Step2 saHpiSensorThresholdsGet

Expected Behavior:

The thresholds set in step1 are equal to the thresholds retrieved in step2

Statements:

Refer to 6.2.3 saHpiSensorThresholdsGet and 6.2.4 saHpiSensorThresholdsSet in HPI specification A.01.01

3.2.34. sensor_type_get(*)

Purpose:

Retrieve the sensor type and event category for the specified sensor

Procedure:

• Step1 retrieve the sensor type and event category using saHpiSensorTypeGet

• Step2* manually check the sensor type and event category

Expected Behavior:

The sensor type and event category retrieved in step1 accords with the existing sensor

Statements:

Refer to 6.2.5 saHpisensorTypeGet() in HPI specification A.01.01

3.2.35. sensor_event_enables_set_enable(*)

Purpose:

Set the enable event message generation status for individual sensor events

Procedure:

• Step1 enable event message generation status

• Step2* manually generate one assertion event and one de-assertion event

• Step3 retrieve events

Expected Behavior:

One assertion event and one de-assertion event are retrieved

Statements:

Refer to 6.2.7 saHpiSensorEventEnablesSet() in HPI specification A.01.01

3.2.36. sensor_event_enables_set_disable(*)

Purpose:

Set the disable event message generation status for individual sensor events

Procedure:

• Step1 disable event message generation status

• Step2* manually generate one assertion event and one de-assertion event

• Step3 retrieve events

Expected Behavior:

No sensor event is retrieved

Statements:

Refer to 6.2.7 saHpiSensorEventEnablesSet() in HPI specification A.01.01

3.2.37. saHpiSensorEventEnablesGet_Set_T1

Purpose:

Retrieve sensor event generation status

Procedure:

• Step1 set sensor event generation status using saHpiSensorEventEnablesSet()

• Step2 retrieve sensor event generation status using saHpiSensorEventEnablesGet()

Expected Behavior:

The status retrieved in Step2 is equal to the status set in Step1

Statements:

Refer to 6.2.6 saHpiSensorEventEnablesGet() and 6.2.7 saHpisensorEventEnablesSet() in HPI specification A.01.01

3.2.38. control_type_get(*)

Purpose:

Retrieve the control type of a control object

Procedure:

• Step1 saHpiControlTypeGet

• Step2* manually check the control type

Expected Behavior:

All control types listed accord with the existing control type

Statements:

Refer to 6.4.1 saHpiControlTypeGet()in HPI specification A.01.01

3.2.39. control_state_set(TBD)

3.2.40. saHpiControlStateGet_Set_T1

Purpose:

Retrieve the current state of a control object

Procedure:

• Step1 saHpiControlStateSet

• Step2 saHpiControlStateGet

Expected Behavior:

The control state retrieved in step2 is equal to the control state set in step1

Statements:

Refer to 6.4.2 saHpiControlStateGet() and 6.4.3 saHpiControlStateSet() in HPI specification A.01.01

3.2.41. saHpiEntityInventoryDataRead_Write_T1

Purpose:

Write inventory data and read it

Procedure:

• Step1 saHpiEntityInventoryDataRead

• Step2 modify the Inventory Data

• Step3 saHpiEntityInventoryDataWrite

• Step4 saHpiEntiryInventoryDataRead

Expected Behavior:

The inventory data retrieved in step 4 is equal to the modified inventory data

Statements:

Refer to 6.5 Entity Inventory Data in HPI specification A.01.01

3.2.42. saHpiWatchdogTimerSet_T1

Purpose:

Set the watchdog timer configuration and restart it

Procedure:

• Step1 configure the watchdog to take no actions using saHpiWatchdogTimerSet

• Step2 saHpiWatchdogTimerReset

• Step3 retrieve events

Expected Behavior:

A watchdog event is retrieved

Statements:

Refer to 6.7 Watchdog Timer and 7.11 Watchdogs in HPI specification A.01.01

3.2.43. saHpiWatchdogTimerGet_T1

Purpose:

Retrieve the current watchdog timer settings and configuration

Procedure:

• Step1 construct a watchdog data

• Step2 saHpiWatchdogTimerSet

• Step3 saHpiWatchdogTimerGet

Expected Behavior:

The watchdog data retrieved in step3 is equal to the constructed watchdog data

Statements:

Refer to 6.7.1 saHpiWatchdogTimerGet() and 6.7.2 saHpiWatchdogTimerSet() in HPI specification A.01.01

3.2.44. autoinsert_timeout_set_immediate(*)

Purpose:

Verify whether the default auto-insertion policy is immediately invoked

Condition:

No event other than hot swap event is generated during testing

Procedure:

• Step1 saHpiAutoInsertTimeoutSet(SAHPI_TIMEOUT_IMMEDIATE)

• Step2* FRU is manually inserted in system

• Step3 retrieve the target events

• Step4 saHpiHotSwapStateGet

Expected Behavior:

• Two target events are retrieved in step 3. The former event is showing transition from "NOT PRESENT" state to" INSERTION PENDING" state. The later event is showing transition from "INSERTION PENDING" state to "ACTIVE/HEALTHY or ACTIVE/UNHEALTHY" state

• The state retrieved in step 4 is ACTIVE/HEALTHY or ACTIVE/UNHEALTHY state

• The gap between two event is very short(how to define short?)

Statements:

Refer to 6.8.7 saHpiAutoInsertTimeoutGet() and 6.8.8 saHpiAutoInsertTimeoutSet()

3.2.45. autoinsert_timeout_set_block(*)

Purpose:

Verify whether the default auto-insertion policy is blocked

Procedure:

• Step1 saHpiAutoInsertTimeoutSet(SAHPI_TIMEOUT_BLOCK)

• Step2* FRU is manually inserted in system

• Step3 retrieve the target event

Expected Behavior:

• The target event is showing transition from "NOT PRESENT" state to" INSERTION PENDING" state

• No event which is showing transition from "INSERTION PENDING" state to "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state is retrieved

Statements:

Refer to 6.8.7 saHpiAutoInsertTimeoutGet() and 6.8.8 saHpiAutoInsertTimeoutSet() in HPI specification A.01.01

3.2.46. saHpiAutoInsertTimeoutGet_Set_T1

Purpose:

Request the auto-insert timeout value

Procedure:

• Step1 saHpiAutoInsertTimeoutSet

• Step2 saHpiAutoInsertTimeoutGet

Expected Behavior:

The timeout retrieved in step 2 is equal to the timeout set in step 1

Statements:

Refer to 6.8.7 saHpiAutoInsertTimeoutGet() and 6.8.8 saHpiAutoInsertTimeoutSet() in HPI specification A.01.01

3.2.47. autoextract_timeout_set_immediate(*)

Purpose:

Verify whether the default auto-extraction policy is immediately invoked

Procedure:

• Step1 saHpiAutoInsertTimeoutSet(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeoutSet(SAHPI_TIMEOUT_ IMMEDIATE)

• Step3* FRU is manually inserted in system

• Step4 retrieve the target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve the target events

• Step7 saHpiHotSwapStateGet

Expected Behavior:

• The target event retrieved in step 6 is showing transition from "EXTRACTION PENDING" state "INACTIVE" state

• The state retrieved in step 9 is "INACTIVE" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.48. autoextract_timeout_set_block(*)

Purpose:

The default auto-extraction policy is blocked

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(SAHPI_TIMEOUT_ BLOCK)

• Step3* FRU is manually inserted in system

• Step4 retrieve the target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve the target events

Expected Behavior:

In step6, No event which

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.49. autoextract_timeout_set_timeout(*)

Purpose:

The default auto-extraction policy is immediately invoked

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(timeout)

• Step3* FRU is manually inserted in system

• Step4 retrieve two target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve two target events

• Step7 saHpiHotSwapStateGet

Expected Behavior:

• The target event retrieved in step 6 is showing transition from "EXTRACTION PENDING" state "INACTIVE" state

• The state retrieved in step 7 is "INACTIVE" state

• The time gap between two event in step6 is timeout specified in step2

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.50. saHpiAutoExtractTimeoutGet_Set_T1

Purpose:

Request the auto-extract timeout value

Procedure:

• Step1 saHpiAutoExtractTimeoutSet

• Step2 saHpiAutoExtractTimeoutGet

Expected Behavior:

The timeout retrieved in step 2 is equal to the timeout set in step 1

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.51. resource_power_set_off(*)

Purpose:

Set the resource to power-off state

Procedure:

• Step1 saHpiResourcePowerStateSet(SAHPI_HS_POWER_OFF)

• Step2* manually check the power state

Expected Behavior:

The resource is in power-off state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.52. resource_power_set_on(*)

Purpose:

Procedure:

• Step1 saHpiResourcePowerStateSet(SAHPI_HS_POWER_ON)

• Step2* manually check the power state

Expected Behavior:

The resource is in power-on state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.53. resource_power_set_cycle(*)

Purpose:

Set the resource into power-cycle state

Procedure:

• Step1 saHpiResourcePowerStateSet(SAHPI_HS_POWER_CYCLE)

• Step2 manually check the power state

Expected Behavior:

The resource is in power-cycle state

3.2.54. resource_power_get

Purpose:

Retrieve the low-level power state of the FRU

Procedure:

• Step1 set power state using saHpiResourcePowerStateSet

• Step2 retrieve power state using saHpiResourcePowerStateGet

Expected Behavior:

• If the power state is set to POWER OFF, then the state retrieved is POWER OFF

• If the power state is set to POWER ON, then the state retrieved is POWER ON

• If the power state is set to POWER CYCLE, then the state retrieved is POWER ON

Statements:

Refer to 6.8.13 saHpiResourcePowerStateGet() and 6.8.14 saHpiResourcePowerStateSet() in HPI specification A.01.01

Comments:

Not all resources supporting managed hot swap will necessarily support this function. An appropriate error code will be returned if the resource does not support power control on the FRU

3.2.55. saHpiHotSwapIndicatorStateGet_Set_T1

Purpose:

Retrieve the Indicator State

Procedure:

• Step1 saHpiHotSwapIndicatorStateSet(SAHPI_HS_INDICATOR_ON)

• Step2 retrieve the power state using saHpiResourcePowrStateGet

• Step3 saHpiHotSwapIndicatorStateSet(SAHPI_HS_INDICATOR_OFF)

• Step4 retrieve the power state using saHpiResourcePowrStateGet

Expected Behavior:

• In step2, the state retrieved is SAHPI_HS_INDICATOR_ON if the function returns SA_OK

• In step4, the state retrieved is SAHPI_HS_INDICATOR_OFF if the function returns SA_OK

Statements:

Refer to 6.8.15 saHpiHotSwapIndicatorStateGet() and 6.8.16 saHpiHotSwapIndicatorStateSet() in HPI specification A.01.01

Comments:

A FRU associated with a hot-swappable resource may include a hot swap indicator such as a blue LED. This indicator signifies that the FRU is ready for removal. Not all resources supporting managed hot swap will necessarily support this function. An appropriate error code will be returned if the resource does not support control of a hot swap indicator on the FRU

3.2.56. hotswap_indicator_set(*)

Purpose:

Set the state of the hot swap indicator

Procedure:

• Step1 saHpiHotSwapIndicatorStateSet(SAHPI_HS_INDICATOR_OFF)

• Step2* manually check the hot swap indicator

• Step3 saHpiHotSwapIndicatorStateSet(SAHPI_HS_INDICATOR_ON)

• Step4* manually check the hot swap indicator

Expected Behavior:

• The function saHpiHotSwapIndicatorStateSet returns error code if the resource does not support control of a hot swap indicator

• In step2, the state of the indicator is off if the resource supports it

• In step4, the state of the indicator is on if the resource supports it

Statements:

Refer to 6.8.15 saHpiHotSwapIndicatorStateSet() in HPI specification A.01.01

3.2.57. hotswap_full_s1_e1(*)

Purpose:

FRU is inserted into system in "NOT PRESENT" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_BLOCK)

• Step2* FRU is inserted in system

• Step3 saHpiEventGet

• Step4 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step 3 is showing transition from "NOT PRESENT" state to "INSERTION PENDING" state

• The state retrieved in step 4 is "INSERTION PENDING"

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.58. hotswap_full_s2_e2(*)

Purpose:

Insertion auto-insert policy completes in "INSERTION PENDING" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2* FRU is manually inserted in system

• Step3 retrieve two target events

• Step4 saHpiHotSwapStateGet

Expected Behavior:

• Two target events are retrieved in step3. The former event is showing transition from "NOT PRESENT" state to" INSERTION PENDING" state. The latter event is showing transition from "INSERTION PENDING" state to "ACTIVE/HEALTHY or ACTIVE/UNHEALTHY" state

• The state retrieved in step4 is ACTIVE/HEALTHY or ACTIVE/UNHEALTHY state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.59. hotswap_full_s2_e3(*)

Purpose:

Call saHpiResourceActiveSet in INSERTION PENDING state

Procedure:

• Step1 saHpiHotSwapControlRequest

• Step2* FRU is manually inserted in system

• Step3 saHpiEventGet

• Step4 saHpiResourcePowerStateSet(SAHPI_HS_POWER_ON)

• Step5 saHpiResourceActiveSet

• Step6 saHpiEventGet

• Step7 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step 6 is showing transition from "INSERTION PENDING" to "ACTIVE/HEALTHY,ACTIVE/UNHEALTHY"

• The state retrieved in step 7 is "ACTIVE/HEALTHY,AC TIVE/UNHEALTHY"

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.60. hotswap_full_s2_e4(*)

Purpose:

FRU is removed from system in INSERTION PENDING state

Procedure:

• Step1 saHpiHotSwapControlRequest

• Step2* FRU is manually inserted in system

• Step3 saHpiEventGet

• Step4* FRU is manually removed from system

• Step5 saHpiEventGet

Expected Behavior:

The event retrieved in step 5 is showing transition from "INSERTION PENDING" state to "NOT PRESENT" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.61. hotswap_full_s3_e4(*)

Purpose:

FRU is removed from system in "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2* FRU is manually inserted in system

• Step3 retrieved two target events

• Step4* FRU is manually removed from system

• Step5 saHpiEventGet

Expected Behavior:

The event retrieved in step5 is showing transition from "ACTIVE/HEALTHY,ACTIVE/UNHEALTHY" state" to "NOT PRESENT" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.62. hotswap_full_s3_e5(*)

Purpose:

Eject latch in "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2* FRU is manually inserted in system

• Step3 retrieve two target events

• Step4* manually eject latch

• Step5 retrieve the target event

• Step6 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step5 is showing transition from "ACTIVE/HEALTHY,ACTIVE/UNHEALTHY" state to "EXTRACTION PENDING" state

• The state retrieved in step6 is "EXTRACTION PENDING"

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.63. hotswap_full_s3_e6(*)

Purpose:

Call saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION) in "ACTIVE/HEALTHY,ACTIVE/UNHEALTHY" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2* FRU is manually inserted in system

• Step3 retrieve two target events

• Step4 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step5 retrieve the target event

• Step6 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step5 is showing transition from "ACTIVE/HEALTHY,ACTIVE/UNHEALTHY" state to "EXTRACTION PENDING" state

• The state retrieved in step6 is "EXTRACTION PENDING"

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.64. hotswap_full_s4_e4(*)

Purpose:

FRU is removed from system in "EXTRACTION PENDING" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2* FRU is manually inserted in system

• Step3 retrieve two target events

• Step4 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step5 retrieve the target event

• Step6 retrieve two target events

• Step7 retrieve the target event

Expected Behavior:

The event retrieved in step7 is showing transition from "EXTRACTION PENDING" state to "NOT PRESENT"

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.65. hotswap_full_s4_e7(*)

Purpose:

Extraction auto-extract policy completes in "EXTRACTION PENDING" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step3* FRU is manually inserted in system

• Step4 retrieve two target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve two target events

• Step7 saHpiHotSwapStateGet

Expected Behavior:

• Two target events are retrieved in step6. The latter event is showing transition from "EXTRACTION PENDING" state "INACTIVE" state

• The state retrieved in step7 is "INACTIVE" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.66. hotswap_full_s4_e8(*)

Purpose:

Call saHpiResourceInActive in "EXTRACTION PENDING" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(SAHPI_TIMEOUT_BLOCK)

• Step3* FRU is manually inserted in system

• Step4 retrieve two target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve the target event

• Step7 saHpiResourceInActive

• Step8 retrieve the target event

• Step9 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step8 is showing transition from "EXTRACTION PENDING" state "INACTIVE" state

• The state retrieved in step9 is "INACTIVE" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.67. hotswap_full_s5_e4(*)

Purpose:

FRU is removed from system in "INACTIVE" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step3* FRU is manually inserted in system

• Step4 retrieve two target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve two target events

• Step7* FRU is manually removed from system

• Step8 retrieve the target event

Expected Behavior:

The event retrieved in step8 is showing transition from "INACTIVE" state to "NOT PRESENT" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.68. hotswap_full_s5_e9(*)

Purpose:

Inject latch in "INACTIVE" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step3* FRU is inserted in system

• Step4 retrieve two target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve two target events

• Step7* inject latch

• Step8 retrieve the target event

• Step9 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step8 is showing transition from "INACTIVE" state to "INSERTION PENDING" state

• The state retrieved in step 9 is "INSERTION PENDING" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.69. hotswap_full_s5_e10(*)

Purpose:

Inject latch in "INACTIVE" state

Procedure:

• Step1 saHpiAutoInsertTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step2 saHpiAutoExtractTimeout(SAHPI_TIMEOUT_IMMEDIATE)

• Step3* FRU is manually inserted in system

• Step4 retrieve two target events

• Step5 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_EXTRACTION)

• Step6 retrieve two target events

• Step7 saHpiHotSwapActionRequest(SAHPI_HS_ACTION_INSERTION)

• Step8 retrieve two target events

• Step9 saHpiHotSwapStateGet

Expected Behavior:

• The event retrieved in step8 is showing transition from "INACTIVE" state to "INSERTION PENDING" state

• The state retrieved in step10 is "INSERTION PENDING" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.70. hotswap_simp_notpresent(*)

Purpose:

FRU is inserted into system in "NOT PRESENT" state

Procedure:

• Step1* FRU is inserted in system

• Step2 saHpiEventGet

• Step3 saHpiHotSwapStateGet

Expected Behavior:

• The state retrieved in step2 is SAHPI_HS_STATE_ACTIVE_HEALTHY or SAHPI_HS_STATE_ACTIVE_UNHEALTHY

• The event retrieved is showing transition from "NOT PRESENT" state to "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01 and Appendix

3.2.71. hotswap_simp_active(*)

Purpose:

FRU is removed from system in "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state

Procedure:

• Step1* FRU is manually inserted in system

• Step2 saHpiEventGet

• Step3 saHpiHotSwapStateGet(State)

• Step4* FRU is manually removed from system

• Step5 saHpiEventGet

Expected Behavior:

The event retrieved in step 5 is showing transition from "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state to "NOT PRESENT"

Statements:

Refer to 6.8 Managed Hot Swap in HPI specification A.01.01

Comments:

• The condition that the state is in "ACTIVE/HEALTHY, ACTIVE/UNHEALTHY" state is made in step 1

• The event is empty in step3 in order to retrieve the event generated by removing FRU

• The state cannot be retrieved because the resource is not present

3.2.72. config_default(TBD)

Purpose:

Restore the factory default settings for a specific resources

Procedure:

• Step1 saHpiParmControl(SAHPI_DEFAULT_PARM)

• Step2 retrieve the current configurations

• Step3 modify the configurations

• Step4 saHpiParamControl(SAHPI_DEFAULT_PARM)

• Step5 retrieve the current configurations

Expected Behavior:

The configurations retrieved in step2 is equal to the configurations retrieved in step 5

Statements:

Refer to 6.9 Configuration in HPI specification A.01.01

3.2.73. config_save_restore(*)(TBD)

Purpose:

Store and restore the configurations

Procedure:

• Step1 modify the configurations and list them

• Step2 saHpiParamControl(SAHPI_SAVE_PARM)

• Step3* manually restart the system

• Step4 saHpiParamControl(SAHPI_RESTORE_PARM)

• Step5 list the current configurations

Expected Behavior:

The configurations listed in step5 is equal to the configuration listed in step1

Statements:

Refer to 6.9 Configuration in HPI specification A.01.01

3.2.74. reset_state_set(TBD)

3.2.75. reset_state_get(TBD)