| commit | 308c3a8bff3d667b43f997856bd884dc15a78ded | [log] [tgz] |
|---|---|---|
| author | Johnathan Mantey <johnathanx.mantey@intel.com> | Wed Jul 22 11:50:54 2020 -0700 |
| committer | Vernon Mauery <vernon.mauery@linux.intel.com> | Wed Aug 05 16:34:20 2020 +0000 |
| tree | cd3406d54c91ade78b5d07f8a8fec5dd072d0c9a | |
| parent | cca2140bb37c1931d9aaf2fb216c99c953a39a0c [diff] |
Allow more than 256 IPMI sensors in a system Systems with more than 255 IPMI sensors report strange values for sensors assigned beyond the 255 limit for a single LUN. This is due to the sensor number assignment rolling over to 0, and then applying the most recent SDR values to the sensor calculation. This change assigns up to 255 sensors to a single LUN (0xFF is reserved). When the 256th sensor is assigned the sensor gets placed in the LUN. LUNs 0, 1, and 3 are used, as LUN 2 is special. Another guard has been created that throws an exception when more than 765 sensors have been assigned. This makes it obvious to the system designer the limit for IPMI sensors has been reached. Tested: Forced the maxmimum number of sensors in the system to be 63 per LUN. "ipmitool sdr elist" returned correct values for every sensor even when the sensor number displayed in the printout matched the value of a sensor printed earlier. "ipmitool sensor get P3V3" returns a valid reading. In my test "P3V3" was in LUN1. "ipmitool raw 4 0x20 0" reported 63 sensors for LUN0, and that LUN0 and LUN1 had sensors. "ipmitool raw -l 1 4 0x20 0" reported the remaining sensor count. "ipmitool raw 0xa 0x2d 0" returns the correct value for LUN0 Sensor 0 "ipmitool raw -l 1 0xa 0x2d 0" returns the correct value for LUN1 Sensor 0 Change-Id: Ic1708b66339e57b1b765f5a9a684e829a0ec8fba Signed-off-by: Johnathan Mantey <johnathanx.mantey@intel.com>
This component is intended to provide Intel-specific IPMI[3] command handlers for OpenBMC. These handlers are intended to integrate BMC with servers based on Intel architecture.
intel-ipmi-oem serves as an extension[1] to OpenBMC IPMI daemon[2]. It is compiled as a shared library and intended to both:
Related features provided by the library are grouped in separate source files. Main extensions to vanilla OpenBMC IPMI stack are the following:
[4]