IPMI version2.0 学习笔记3

Last Processed Event Tracking
     Last Software Processed Event和Last BMC Processed Event分别记录software和BMC处理的SEL Record得ID号。它们的值可以通过Set Last ProcessedEvent ID和Get Last Processed Event ID commands来设置和获得。
       如果PEF是不可用的，那么the Last BMC-processed Event记录SEL的最后一条记录。如果Clear SEL将会自动清除上面的两个值。
       如果PEF是可用的，但是BMC断电或者重启的话，那么等到BMC正常之后，自动运行PEF，处理那些没被其处理的SEL里的记录。
       PEF可用，当检测到SEL中存在未被software处理过的记录时，PEF Postpone timer将会自动启动。如果该timer正在运行中时接收到新的event，那么timer不会自行运行，software先Set Last ProcessedEvent ID，之后timer才能运行。
Event Processing When The SEL Is Full
         若SEL满了，新的event被放入Event Message Buffer，如果Event Message Buffer也满了，那就必须先清除Buffer，才能继续放。
         若PEF被实现，events会被放入‘hidden’ internal queue or buffer，如果满了，就必须开辟新的空间，否则不能再放。
         如果上面的两个都未被实现，那么一旦SEL满了，event将被BMC拒绝。
         ‘SEL Aging’用来自动清除一定时间内的的SEL记录的，algorithm必须设置the SEL ‘most recent erase timestamp’来反映被清除的时间。可以通过系统配置来关闭aging algorithm。

PEF Actions
         BMC会扫描这个列表，收集action。action会按照优先级执行。一个alert可以和其他action一起执行。power down, power cycle, and reset actions不能同时执行，如果发生这种情况，只有优先级最高的被执行。（ 优先级表见P247/Table 17-1 ）

Event Filter Table
       一个单一event还是一个多重event，对应一条entry。
       建议至少存在16条entry（包括：over-temperature, power system failure, fan failure events等，还应该包括可让OEM和System Management Software进行事件配置的entry。），还可以对有些entry加标签，用来让系统在必要时进行重新配置。
       在new event和BMC启动时的pending events，这两种情况下PEF不会起作用的。

Event Data 1 Event Offset Mask（2 bytes）
       Event Filter里的Event Data 1 Event Offset Mask field用来匹配多个bits，这些bits位于Event Offset field of the Event Data 1 byte of an event。典型的是event data 1的最小最重要的nibble保存着一个event offset value。对于一个sensor这个offset在不同的可能的events中进行选择。例如，一个‘button’sensor支持一系列sensor-specific event offsets：0表示Power Button pressed，1代表Sleep Button pressed，2代表Reset Button pressed。当一个event产生时，会根据哪一个button press发生从而在event offset field中对应是0、1或者2。
         Event Offset Mask使得filter能够非常简单地匹配上可能的event offset values集合。mask中的每一个bit对应一个offset value，在mask中从bit 0对应offset 0开始。例如，如果希望一个filter匹配上offset 0和2且不要1，那么mask会被配置成0000_0000_0000_0101b。
Using the Mask and Compare Fields
         AND Mask、the Compare 1和Compare 2 fields被联合，用来允许在corresponding event data byte的bit之间进行wildcarding, ‘one or more bit(s)’, and exact comparisons 。理解bits的一个方法是了解它们在联合中被用的方法。首先AND Mask被用在test value。然后test value依据Compare1 and Compare 2 fields中的value进行bit-wise匹配。

Alert Policy Table
         alert的media和destination是通过Alert Policy Table中的设置决定的。
           每一个table entry也包含一个参数用来选择一个alert是否要发到所有可用的destination或者是不同的destination，entry还可以改变一个destination是否能被处理。
           一个policy number把多个table entry组成一个policy set。这种集合决定了哪些media和alert type在alert action发生时是可用的。配置Platform Event Filter table entry是用来当一个event发生时决定运行哪个action，alert policy number也是用来配置这个alert action的。BMC寻找并利用policy number在 Alert Policy Table中找出相应的policy set.
         policy number 也可以决定alert policy的优先级。只能有一个alert policy用到一个给定的event。如果一个event匹配上了几个alert policy，那么只有那个最小的数字的被使用。要支持alert的实现就至少要提供一个alert policy table entry。建议对于一个可以传alert的channel，应该有一个policy table entry支持。

Alert Testing
         BMC有测试alert配置的能力，用的是 Alert Immediate command 。这个命令允许一个特殊的alert destination被选择，并向它发一个alert。特别是software可以在为一个channel配置时利用这个可变的设置来保存alert destination的信息，直到这个设置被user核实哪一次可以将其移入固定的位置。

Alert Processing
         对于Alert的处理，BMC开始于Alert Policy Table。最开始是扫描Event Filter table所有的entry用来匹配event，然后启动优先级最高的那个Alert Policy。如果有多个filter匹配上并且Alert Policy的优先级相同，则第一个被匹配上的event filter被应用。
          BMC被允许在同一个channel上或者多个channel上同时处理多个 alert。
         如果一个alert被成功发送，BMC要么停止处理policy，要么继续处理alert policy table entries，这取决于destination被配置成当成功之后stop alert processing 还是not stop alert processing。
         在alert policy中每一个entry被按次序处理直到所有的entry都已经被处理（意味着alert either sent,failed, or the alert was skipped）。
Alert Processing after Power Loss
           当一个alert正在被处理时可能会有很多的event进来。每一次alert的SEL记录被completely processed之后，BMC会将这个Last BMC Processed Record ID拷贝一份到NV storage。（completely processed意思是对于这个event没有未被完全地处理的alert policy）。照此，如果AC power失效了，BMC会比较Last BMC Processed Record ID和SEL里最后一个entry的Record ID来告诉是否存在未别处理的alert的event。
             一个alert可能会被发送到多个destinations，但是当断电时，不一定都会已经完成。当重新上电时，BMC将会开始处理所有的event record，这样就会导致一些alert会被重复发送。
Processing non-Alert Actions after Power Loss
             BMC上电后且系统电源状态恢复前，BMC会使用PEF去check pending events是否会产生‘power off’的action。如果存在这种event，BMC将会设置先前的恢复状态为off，而且使system为power off。如果AC丢失，BMC将会跳过pending的正在处理的reset或者power cycle action。
           为了得知有多少event要处理，BMC将会拷贝last SEL Entry的Record ID or timestamp而且仅仅处理那些当AC丢失时，仍在pending的event的records。照此，如果一个新的event产生，它将会被作为一个新的event来处理，而不是AC丢失时仍在pending的event。
Alert Processing when IPMI Messaging is in Progress
           如果IPMI Messaging正在被处理，那么它所在的channel上的alert都会被延迟。remote console software可以指导BMC通过将所有filter的Last BMC Processed Record ID设置成Record ID of the last SEL Record来跳过正在处理的延迟的event。
Sending Multiple Alerts On One Call
             为避免不必要的phone calls， 通常希望在挂断之前可以将多个alerts 发送到一个给定的PPP Account，而不是在每一个event之后都会挂断。serial/modem configuration parameters和Alert Policy entries可以被配置从而支持这个。为了实现这个，configuration必须满足下面规则。
             *****PPP Accounts的Connection Hold Time parameter应该被设置成一个值，这个值包括你想要call保持连接状态等待下一个event发生的时间。因为一个新的alert会重新开启连接的时间定时，所以这个值必须被设置成必需的时间，以维持alerts之间的连接。
             *****所有的event policy应该被配置成alerts在每一个channel上都按照优先级顺序被传输，其中优先级最高的排在最前面。
Serial/Modem Alert Processing
             在同一个serial/modem channel上alert的处理是依照优先级的。PPP Accounts alerts的优先级高于Dial Page or TAP Page alerts。 PPP Accounts又根据account的选择区分优先次序，其中较小的account selector对应较高的优先级别。
           以下是在同一个channel如何处理serial/modem alerts的规则：
             ***BMC不会过早的结束一个给定destination的正在处理中PPP Alert, Dial Page, or TAP Page，除非一个用来处理power off, power cycle的执行被允许，或者system reset transition。在这种情况下，一旦transition完成，alert应该重新开始。
           ***BMC检查event filters来匹配event。如果有好几个alert policy被匹配上，BMC只会运行一个优先级最高（即序号最小） 的alert policy。
           ***BMC会追踪它处理event相关的alert已经走到了哪里。这样做以防因为a power off, power cycle, or system reset操作，它需要过早的停止这个call。
           ***BMC从头到尾处理每一个alert policy，直到完成。这句话中”完成“的意思是所有alert要么被发送，要么被延迟。
           ***如果目前没有active connection，将会建立一个connection在刚刚发出alert的alert policy中的的first alert destination。
         ***PPP Account Connection Hold Time parameter决定一个PPP call在下一个alert到达之前可以等待多长时间。PPP connection将会在时间停止或者一个更高优先级的alert发生时结束。
         ***如果对于给定policy的所有destination，alert都是失败的。那么对于一个PPP Account的call不会等待Connection Hold Time，就会被放弃。
         ***不管任何时候一个alert被发送到特定account，Connection Hold Time time-out必须被重启。
         ***如果PPP account connection已经active且alert在这个PPP account之后已经被发向了一个destination，那么BMC将会等待正在发向该account的任何alert完成才会去发送present alert。
         *** 如果一个alert发向一个destination,这个destination在一个更高优先级PPP account之后，那么present 连接将会被终止只要present alert的account已经完成,无论connection拥有的时间。BMC

将会拨号优先级更高的account，然都发送alert。
         ***如果一个PPP account connection已经被打开，它将会被一直使用直到这个alert被发向一个优先级更低的destination type。在这种情况下，这个alert将会被延迟直到present connection的connection hold time停止。
         ***如果一个Dial Page or TAP Page已经active，BMC将会等待这个正在进行的alert完成然后发送present alert无论present alert是否拥有更高的优先级。（对于一个in progrss的unacknowledged alert的完成意味着这个alert已经被发出。对于一个acknowledged alert，完成意味着alert已被发送且acknowledge被收到了，或者retry和timeouts已经结束alert被认为失败。）
       ***Page Blackout Interval实质上是一个'throttle'用来防止pages被接连不断的发送。     
 
17.5和17.6中的两个图很值得一看！