Receive Event
更新时间： 2026/08/06
在Gitcode上查看源码Receive Event
Change History
| openUBMC Version | Revision Date | Description |
|---|---|---|
| 25.06 | 2025/06/26 | Initial draft: add command details |
Basic Information
Function Description
Indicates the event reporting command.
Privilege
Command Information
Request Information
| Byte | Data Field |
|---|---|
| NetFn | 30h |
| CMD | 94h |
| 1:3 | Manufacturer ID, LS Byte first. The length is fixed to three bytes. For example, if the vendor ID is 2011 and the corresponding hexadecimal value is 0x0007DB, the first byte is DBh, the second byte is 07h, and the third byte is 00h. |
| 4 | Sub command, sub command=33h |
| 5:08 | New event ID, in the little endian format. The SMM uses the new event ID to interact with the BMC. The new event ID uniquely identifies an event. |
| 9:12 | Old event ID, in the little endian format. If there is no old event ID, this field is set to 0. To ensure compatibility, the SMM uses the old event ID to generate a TRAP OID when assembling an SNMP TRAP OID. Otherwise, the SMM uses the new event ID to generate a TRAP OID. |
| 13 | Indicates the event type of a sensor event, which is used to calculate the SNMP TRAP OID based on the old event code. |
| 14 | Indicates the sensor type of a sensor event, which is used to calculate the SNMP TRAP OID based on the old event code. |
| 15 | Segment ID, 1 based. For a high-performance server 9032, each segment indicates a 4-socket system. The segment ID is used to identify a 4-socket system. The value 0 indicates that this parameter is not involved. |
| 16 | Indicates the group ID. If the slot ID (silkscreen number) of a product is duplicate, the group ID is used to identify the memory board. For example, the group ID of a memory module installed on a memory board is the same as that of a memory module installed on another memory board. |
| 17:18 | Indicates the event body number, which starts from 1 and increases in the same sequence as the silkscreen number. 0xff indicates all event bodies of the specified segment and group. If the value is 0, it indicates that the event body is not involved. |
| 19:20 | Event sequence number, in the little endian format. The value ranges from 1 to 65535. |
| 21:24 | Indicates the time when the alarm is generated, which is the number of seconds since 00:00:00 on January 1, 1970. |
| 25 | Serverity: indicates the severity level. 0-Normal1-Minor2-Major3-Critical |
| 26 | Event Category 0: system event1: maintenance logRun log3: equipment event (Currently, only the system event is supported.) |
| 27:28:00 | Reporting Protocol bit0: local recordbit1: IPMI (management module)bit2: SNMP Trapbit3: syslogbit4: e-mailbit5: RESTful, little endian |
| 29 | Event-triggered method 1: normal monitoring 2: analog 3: manually triggered recovery event 4: Re-report after receiving the re-report command. The meaning is the same as the value of the Mode attribute of the event monitoring object. |
| 30:33:00 | Event mutex code, in the little endian format. If this parameter is not involved, set it to 0. |
| 34 | [7:1]: reserved [0]: cascading flag 0: last data 1: middle data |
| 35:36:00 | Offset, indicating the offset of the written data. The value starts from 0. |
| 37:38:00 | Write data in sequence when they are written as multiple frames. Length: indicates the length of the written data. |
| 39:N | data1:1 - Length of the event body name data2:N - Event subject name NOTE: The event body name consists of two parts, which are separated by two horizontal bars (--). The first part is the sensor name or event body name. The sensor name is preferred. The name of the new non-sensor event is the event body name. Some NMSs are bound with sensor names. The reported sensor names are used to enable the SNMP TRAP of the SMM/CMC to be compatible with the NMS.The last part is the additional identification information, which consists of one or more dynamic event description parameters of the event monitoring object. The horizontal bar and the last part are optional. Format 1: lang_xxx_str=[Event body name] NOTE: The multi-language event reporting format is implemented on the receiving side. The event description, handling suggestions, and dynamic data are similar to those of the multi-language event reporting format. Format 2: lang_xxx_str NOTE: If multi-language events cannot be implemented or do not need to be implemented, the English event body name is reported in this format. The meaning of dynamic data is similar to that of multi-language events. Format 3: [Event body name] NOTE: The language ID has a mapping relationship with the software version on the receiving side (generally, a third-party module reports an event to the BMC) or the language ID is incompatible. For example, if the format of the event description or handling suggestion of an event is changed and incompatible, the language ID cannot be identified after the system is rolled back to an earlier version. Solution: Use this format to assign values to attributes such as event description or handling suggestion in the lang_xxx_str=xxxxxx format (xxxxxx is the new format of event description or handling suggestion). The meanings of event description, handling suggestion, and dynamic data are similar. data (N+1):2 indicates the length of the event description, in little endian format. data (N+3):M: event description (including the event subject and location [optional]) Format 1: lang_xxx_str=[Event description] [0xba] Dynamic data 1[0xba] Dynamic data 2[0xba] Dynamic data 3[0xba] Dynamic data 4Format 2: lang_xxx_str[0xba] dynamic data 1[0xba] dynamic data 2[0xba] dynamic data 3[0xba] dynamic data 4 Each piece of dynamic data is in the following formats: lang_xxx_str, lang_xxx_str=xxxxx, or xxxxx. NOTE: The number of dynamic data N is optional. The N values are separated by invisible characters 0xba. A maximum of 10 dynamic data records can be reserved. data (N+2+M):2 indicates the length of the handling suggestion, in little endian format. If the length is 0, no handling suggestion is provided. data (N+4+M):L-Handling suggestion content Format 1: lang_xxx_str=[Handling suggestion] [0xba] Dynamic data 1[0xba] Dynamic data 2Format 2: lang_xxx_str[0xba] dynamic data 1[0xba] dynamic data 2 Each piece of dynamic data is in the following formats: lang_xxx_str, lang_xxx_str=xxxxx, or xxxxx. NOTE: The number of dynamic data N is optional. The N values are separated by invisible characters 0xba. A maximum of 10 dynamic data records can be reserved. data (N+4+M+L): 4 - Health mutex code. |
| Note: To reduce the BMC development workload, the first version does not report the handling suggestion information to the management module. The handling suggestion length in the command is 0.The event description and handling suggestion must have the corresponding multi-language ID. However, the event body name and dynamic data cannot or do not need to have the corresponding multi-language ID in most cases. Therefore, the multi-language ID is not required and the event body name and dynamic data are displayed or reported in English. |
Response Information
| Byte | Data Field |
|---|---|
| 1 | Completion Code |
| 2:04 | Manufacturer ID, LS Byte first. The length is fixed to three bytes. For example, if the vendor ID is 2011 and the corresponding hexadecimal value is 0x0007DB, the first byte is DBh, the second byte is 07h, and the third byte is 00h. |
| 5 | data1:1: indicates whether the event receiving side implements the event multi-language function. 0: Not implemented. The items with multi-language IDs on the sending side are reported in the lang_xxx_str=xxxxx format. Otherwise, the items are reported in the xxxxx format. 1: yes. In this case, the items with multi-language IDs on the sending side are reported in the lang_xxx_str format. Otherwise, the items are reported in the xxxxx format. |
Command Example
Event reporting command.
Request:
bash
ipmicmd -k "0f 00 MM NN" smi 0Response:
text
0f MM NN