Alert Standard Format (ASF) Specification

Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136
DSP0136 23 April 2003 Page 84 of 94
Appendix A Additions to PET Specification 1.0
A.1 Modem Support
There needs to be a new entry for the Trap Source Type and Event Source type for Modems.
60h – 67h
A.2 Battery Sensor
To support system battery-related events a new Event Sensor Type along with a set of Sensor-
specific Offsets should be added as follows:
Battery 29h 00h Battery low
01h Battery failure
02h Battery presence detected
A.3 System Firmware Error/Progress Descriptor
To support industry-standard system progress and error handling, the “POST Error” Sensor Type
defined by [PET_1.0] is renamed and extended as described below.
Sensor Type
Sensor
Type
Code
Sensor-
specific
Offset
Event
00h
Standard System Firmware Error. The Event Data
2 field contains a further error descriptor, as
described in 3.1.5.2 System Firmware Error Events
01h
Standard System Firmware Hang. The Event Data 2
field contains a further error descriptor, as described
in 3.1.5.3 System Firmware Progress Events.
02h
Standard System Firmware Progress. The Event
Data 2 field contains a further progress descriptor,
as described in 3.1.5.3 System Firmware Progress
Events.
03h OEM-specific System Firmware Error.
04h OEM-specific System Firmware Hang Error
System Firmware
Error/Progress
Descriptor
0Fh
05h OEM-specific System Firmware Progress
A.4 Device Relative Entity Instances
The present PET specification defines an Entity Instance number that identifies different
instances of the same entity type in the system. For example, if you have three fans, the entity
instance value allows you to tell one fan from another by allowing an Entity Instance number to be
assigned. Typically, a system with three fans would assign instance numbers 1, 2, and 3 to the
fans - though there is no requirement that instance numbers be consecutive or sequential starting
from 1.
The Entity Instance numbers are presently assigned relative to the entire system. Which means
that a given number can only be used once in the entire system. This leads to a problem for add-
in devices, or pre-configured sub-systems. For example, you could not pre-assign entity instance
numbers to entities on an add-in card, because if you put two identical cards in the system, their
instance numbers would conflict.
Thus, the definition of Entity Instance number needs to be changed to allow sensor device
relative instance numbers. The following table shows the proposed change to accomplish this by
splitting the entity instance number into two ranges: one for system relative and another for
sensor device relative.