14.6.1 ‘Global’ Re-arm
2 comparison description
15.8 Event Data 1 Event Offset Mask
The Event Data 1 Event Offset Mask field in the Event Filter is used to match multiple bits in the Event Offset field of the Event Data 1 byte of an event. The least significant nibble of event data 1 typically holds an event offset value. This offset selects among different possible events for a sensor. For example, a ‘button’ sensor supports a set of sensor-specific event offsets: 0 for Power Button pressed, 1 for Sleep Button pressed, and 2 for Reset Button pressed. When an event is generated, it could have a 0, 1, or 2 in the event offset field depending on what button press occurred.
The Event Offset Mask makes it simple to have a filter match a subset of the possible event offset values. Each bit in the mask corresponds to a different offset values starting with bit 0 in the mask corresponding to offset 0. For example, if it is desired to have a filter match offsets 0 and 2, but not 1, the mask would be configured to 000_0000_0000_0101b.
15.9 Using the Mask and Compare Fields
The AND Mask and the Compare 1 and Compare 2 fields are used in combination to allow wildcarding, ‘one or more bit(s)’, and exact comparisons to be made between bits in the corresponding event data byte. One way to understanding the bits is to look at the way they’re used in combination. First the AND Mask is applied to the test value. The result, referred to below as the test value, is then bit-wise matched based on the values in the Compare 1 and Compare 2 fields, as summarized in the following table.
Table 15-3, Comparison-type Selection according to Compare Field bits
Compare
1 Compare
Example 2: Match (bit 2 = 1) OR (bit 1=1), and ignore all other bits.
AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0.
Compare 1: 1111 1001 Compare for at least one of bit 2 or bit 1being polarity specified in the corresponding bit position in Compare 2. Compare remaining bits exactly.
Compare 2: 0000 0110 Compare for bit 2 or bit 1 = 1, and remaining bits = 0 exactly.
Example 3: Match (bit 2 = 1) AND (bit 1 = 0) AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0 Compare 1: 1111 1111 Compare all bits (after AND) exactly
Compare 2: 0000 0100 Compare for bit 2 = 1 and bit 1 = 0, and remaining bits = 0 exactly.
Example 4: Match bit 2 = 1 OR bit 1 = 0
AND Mask: 0000 0110 Force all bits except bits 2 and 1 to 0.
Compare 1: 1111 1001 Compare all bits except bits 2 and 1 exactly.
Compare 2: 0000 0100 Compare for bit 2 = 1 OR bit 1 = 0, and remaining bits = 0 exactly.
Example 5: Match most significant nibble = 1010 exactly, and any bit in LSN = 1.
AND Mask: 1111 1111 Look at all bits
Compare 1: 1111 0000 Compare all bits in MSN exactly.
Compare 2: 1010 1111 Compare MSN = 1010 exactly, and for a 1 in one or more positions in LSN Example 6: match MSN = 1010 exactly, and any bit in LSN = 0.
AND Mask: 1111 1111 Look at all bits
Compare 1: 1111 0000 Compare all bits in MSN exactly.
Compare 2: 1010 0000 Compare MSN = 1010 exactly, and for a 0 in one or more positions in LSN
15.11 Alert Policy Table
Platform Event Filtering supports alerting as one of the selectable actions that can occur when an event matches an event filter table entry. The alerting media and the different alert destinations that are tried are determined by the settings in the Alert Policy Table.
The Alert Policy Table definition enables implementations to offer multiple policy sets. For example, one policy could be configured to generate LAN Alerts and Pages and be associated with critical and non-recoverable events, while another may generate only LAN Alerts and be associated with non-critical events. It would even be possible to configure a ‘Chassis Security’ event to notify one party, while an ‘Over-temperature’ event could be delivered to a different destination.
The table entry also contains a parameter that can be used to select whether the alert is delivered to all enabled destinations, or that different destinations are tried until the alert is successfully delivered. Altering the policy table entries can change the whether certain destinations are processed or not.
A policy number is used to group multiple table entries into a policy set. The collection of entries determines which different media and alert types can be tried when an alert action occurs. When a Platform Event Filter table entry is configured to perform an alert action on an event, an alert policy number is also configured for the action.
The BMC takes this policy number and uses it to look up the entries for the corresponding policy set in the Alert Policy Table.
The policy number also determines the priority of alert policies. Only one starting Alert policy will be used for a given event. If an event matches more than one alert policy, the policy with the lowest number will be used.
Implementations that support alerting are required to provide at least one table entry. It is recommended that an implementation supports at least one policy table entry for each different channel over which an alert can be delivered.
Table 15-4, Alert Policy Table Entry
Byte Field Description
DATA BYTES
1 Policy Number / Policy
This value identifies the entries belonging to a particular policy set. When an Alert Action is taken, the BMC will scan the Alert Policy Table and will attempt to generate alerts based on the entries that form the policy set.
[7:4] - policy number. 1 based. 0000b = reserved.
[3] - 0b = this entry is disabled. Skip to next entry in policy, if any.
1b = this entry is enabled.
[2:0] - policy
0h = always send alert to this destination.
1h = if alert to previous destination was successful, do not send alert to this destination.
Proceed to next entry in this policy set.
2h = if alert to previous destination was successful, do not send alert to this destination.
Do not process any more entries in this policy set.
3h = if alert to previous destination was successful, do not send alert to this destination.
Proceed to next entry in this policy set that is to a different channel.
4h = if alert to previous destination was successful, do not send alert to this destination.
Proceed to next entry in this policy set that is to a different destination type.
2 Channel / Destination Channel that the alert is to be sent over. Channel determines which set of destination addresses or phone numbers is used. Destination addresses and/or phone numbers are set via the LAN and/or serial/modem configuration parameter commands. The Alert Type (e.g.
PET, TAP, Dial Page, etc.) is specified in the configuration parameters associated with the specified destination.
[7:4] = Channel Number.
[3:0] = Destination selector.
3 Alert String Key This field holds information that is used to look up the Alert String to send for this Alert Policy entry.
00h = no alert string.
[7] - Event-specific Alert String
1b = Alert String look-up is event specific. The following Alert String Set / Selector sub-field is interpreted as an Alert String Set Number that is used in conjunction with the Event Filter Number to lookup the Alert String from the PEF Configuration Parameters.
0b = Alert String is not event specific. The following Alert String Set / Selector sub-field is interpreted as an Alert String Selector that provides a direct pointer to the desired Alert String from the PEF Configuration Parameters.
[6:0] - Alert String Set / Selector. This value identifies one or more Alert Strings in the Alert String table. When used as an Alert String Set Number, it is used in conjunction with the Event Filter Number to uniquely identify an Alert String. When used as an Alert String Selector it directly selects an Alert String from the PEF Configuration Parameters.
The Alert String Key and lookup mechanism allows the Alert String to be ‘Event Specific’ - meaning the string selection is determined by both the Event Policy Entry and Event Filter, or, the string can be selected by the Event Policy alone. An Alert String can be pointed to by multiple policy entries.
The Alert Policy Entry identifies a particular channel and destination for an alert. This in turn, identifies the alert type. Thus, the binding of an Alert Policy Entry and an Alert String effectively provides a mechanism for allowing different Alert Strings to be selected based on the alert destination, or the type of alert destination. For example, a single Alert String could be shared among all Alert Policy Entries for ‘Dial Page’ destinations, while event-specific Alert Strings could be used for alerts to LAN destinations.
15.12 Alert Testing
BMC includes an ability to test alert configurations. This is accomplished through the Alert Immediate command.
This command allows a particular alert destination to be selected and an alert sent to it. Typically, software will use the volatile settings in the configuration parameters for the channel to hold alert destination information until the setting is verified by the user, at which time it can be moved into one of the non-volatile positions.
15.13 Alert Processing
The BMC starts from the beginning of the Alert Policy Table, scanning for entries that match the event. The BMC will scan all entries in the Event Filter table and initiate the highest priority Alert Policy for which there was a match. If multiple filters match and have the same alert policy priority, the first matched event filter will be used.
(Since an Alert String can be associated with an event filter, it may be important to order the event filter table such that the more ‘granular’ filters occupy the earlier entries, and the more generic filters occupy the later entries.) BMC implementations are allowed to have multiple alerts simultaneously in progress on the same channel or across multiple channels.
If an alert was successfully delivered, the BMC will either stop processing the policy, or will continue to process alert policy table entries - based on whether the destination was configured to stop alert processing on success or not. Each entry in the alert policy is processed in order until all entries have been processed (meaning the alert was either sent, failed, or the alert was skipped).
15.13.1 Alert Processing after Power Loss
It is possible that more events will come in while an alert is being processed. Each time a SEL Record is completely processed for alerts, the BMC saves a copy of the Last BMC Processed Record ID to NV storage.
(“Completely processed” means that there are no incompletely processed alert policies for the event). That way, if AC power is lost the BMC can tell whether there are events that may not have been processed for alerting by comparing the Last BMC Processed Record ID with the Record ID of the last SEL Entry.
It’s possible that alerts were sent to some destinations, but not all, when power was lost. When power comes back up, the BMC will start processing the entire record and as a result some alerts may get re-sent.
15.13.2 Processing non-Alert Actions after Power Loss
After the BMC powers up, and before restoring the system power state, it uses PEF to check pending events for matches that would have yielded a ‘power off’ action. If there is a match, it sets the previous power Restore State to Off and leaves the system powered off. The BMC skips processing reset or power cycle actions that were pending when AC was lost.
In order to know how many events to process, the BMC should copy the Record ID or timestamp of the last SEL Entry and only process records up to that point as events that were pending when AC was lost. That way, if a new event comes in, it will be handled as a new event rather than as an event that was pending when AC was lost.
15.13.3 Alert Processing when IPMI Messaging is in Progress
All alerts are deferred if IPMI Messaging is in progress on the channel. The remote console software can direct the BMC to skip processing deferred events by setting the Last BMC Processed Record ID value for all filters to the Record ID of the last SEL Record.
15.13.4 Sending Multiple Alerts On One Call
To avoid unnecessary phone calls, it is desirable to have multiple alerts be delivered to a given PPP Account before hanging up, rather than hanging-up after each event. The serial/modem configuration parameters and the Alert Policy entries can be configured to support this. To have this accomplished, the configuration must fit the following rules.
• The Connection Hold Time parameter for the PPP Accounts should be set to a value that covers the time that you’d like the call to be maintained waiting for the next event to occur. Since a new alert will restart the
connection time time-out, the value should be set to the time required to maintain the connection between alerts.
• All event policies should be configured to have alerts to each channel delivered in priority order starting with the highest priority destination first.
15.13.5 Serial/Modem Alert Processing
Alerts on the same given serial/modem channel processed according to priority. Alerts to PPP Accounts are processed with higher priority than Dial Page or TAP Page alerts. PPP Accounts are prioritized according to the account selection, with the lowest account selector corresponding to the highest priority with the lowest account selector as summarized in the following table:
Table 15-5, Serial/Modem Alert Destination Priorities
Destination Type
Priority
(0 = highest) Comments
PPP Account #1 1
PPP Account #2 2
PPP Account #N N
All destinations behind a given PPP Account are at equal priority. Destinations behind an account are handled in the order that they occur in the Alert Policy Table entry associated with the account.
Dial Page and TAP Page N+1 All Dial Page and TAP Pages are at equal priority. They are handled in the order that they occur in the Alert Policy Table entry.
The following specifies how serial/modem alerts from the same channel are handled:
• The BMC will not prematurely terminate a PPP Alert, Dial Page, or TAP Page in progress to a given destination, with the exception that an implementation is allowed to in order to handle a power off, power cycle, or system reset transition. In this case, the alert should be resumed once the transition has completed.
• The BMC checks the event filters for matches to the event. If there is more than one alert policy selected by the match, the BMC will only execute the highest priority (lowest numbered) alert policy.
• The BMC must keep track of how far it has processed the alert policy associated with the event. It does this in case it needs to prematurely terminate a call because of a power off, power cycle, or system reset operation.
• The BMC processes each alert policy through to completion. Completion of processing means that all alerts were either sent or deferred.
• If there is no presently active connection, a connection will be made for the first alert destination in the alert policy sent and the alert sent.
• The PPP Account Connection Hold Time parameter determines how long a PPP call will be held open waiting for another alert. The PPP connection will only close when the time expires, or if an alert to a higher priority PPP Account occurs.
• The call to a PPP Account will be dropped without waiting for the Connection Hold Time to expire if alerts fail to all destinations for a given policy.
• The Connection Hold Time time-out must be restarted whenever a new alert is sent to the account.
• If a PPP account connection is already active and the alert is to a destination behind that PPP account, the BMC will wait for any alerts in progress to that account to complete and then send the present alert.
• If the alert is to a destination that is behind a higher priority PPP account, the present connection will be terminated as soon as the present alert to that account has completed, regardless of the connection hold time. The BMC will then dial the higher priority account and sent the alert.
• If a PPP account connection is already open it will be used unless the alert is to a lower-priority destination type, in which case the alert will be deferred until connection hold time for the present connection expires.
• If a Dial Page or TAP Page is already active, the BMC will wait for the alert in progress to complete and then send the present alert, regardless of whether the present alert is of higher priority. (Completion of an alert in progress for an unacknowledged alert means that the alert has been sent. For an acknowledged alert, completion means the alert has been sent and the acknowledge received or all retries and timeouts have concluded and the alert is considered to have failed.)
• The Page Blackout Interval is essentially a ‘throttle’ that prevents pages from being sent ‘back-to-back’. See 13.10, Page Blackout Interval.
15.14 PEF and Alert Handling Example
The following figure presents a snapshot of event and alert processing using PEF. It also helps illustrate the relationship between entries in the serial/modem configuration parameters.
1. The present event being processed is identified as event with Record ID = “N+2”
2. The BMC scans all filter table entries for matches to the present event. When done, it finds three entries with Alert actions that have been matched: event filters X, P, and T.
3. The BMC handles matched filters in priority order based on the action associated with the filter. The Power Off action is higher priority than Alert actions, so filter X is acted on immediately and the power OFF action performed.
4. There are two matched filters left, both with Alert actions. Filter P is acted on because it has the lower policy number. The BMC ‘queues’ information for the alert policy and the event filter so it can be processed later.
5. The event triggers Alert Policy #3. The BMC sends the alert to LAN destination #1, and then sends the alert to serial/modem destination #1. The figure shows that serial/modem destination #1 is a PPP Alert destination, therefore the BMC looks up the corresponding PPP Account information from the serial/modem configuration parameters. The PPP account is account #1. This is the highest priority account. If the account is not already active, the BMC will terminate any lower priority call in progress and then call the account #1 and send the alert.
6. The completion of the alert policy for event N+2 may cause the Last BMC Processed Record ID to be set to N+2 - but it also may not. Whether the Last BMC Processed Record ID is advanced is based on whether all deferred alerts have been processed. Due to prioritization, it’s possible that in some cases the alert policy triggered for event N+2 could complete while an alert policy associated with an earlier event ‘N’ could still have destinations to be processed.