mohandev2
commented
13 years ago - priority: 5 --> 3
Original comment by: v8kip
Open mohandev2 opened 13 years ago
mohandev2
commented
13 years ago Original comment by: v8kip
mohandev2
commented
13 years ago Original comment by: v8kip
mohandev2
commented
13 years ago Original comment by: v8kip
We are using openhpi to get some IPMI OEM sensor types from the HW. According to the IPMI Spec the OEM sensor type range is C0h-FFh.
Intelligent Platform Management Interface Specification v1.5 Document Revision 1.1
Chapter "36.2 Sensor Type Codes and Data" Table 36-3, Sensor Type Codes OEM RESERVED C0h-FFh
For the older openhpi versions and also for the newest 2.16.0 version the "plugins/ipmi/ipmi_sensor_event.c" and the "plugins/ipmidirect/ipmi_sensor.cpp" files are overwriting the OEM sensor type codes with SAHPI_OEM_SENSOR (i.e. C0h value) e.g.
if (data[7] >= 0xc0) { e->event.EventDataUnion.SensorEvent.SensorType = SAHPI_OEM_SENSOR; }
This is not really a problem since in this case we then check the sensor number which is different for the different sensor types. But I'm wondering what is the reason for overwriting all the OEM sensor types with the C0h value? Is it just to make the coding a bit easier since you only check for the C0h value and not for the range of C0h-FFh? And the the sensor numbers are actually used to differentiate between different OEM sensor types?
Btw, when enabling the log dumping feature of openhpi the real OEM sensor type will be showed in the log dump (even though value 0xc0 is returned to the caller): 2011.06.16 09:19:48.140 SensorType = 0xc8;
Creating this bug report as requested by Anton Pak in "[Openhpi-devel] Question about SAHPI_OEM_SENSOR sensor type" mail thread.
If this is not fixed since it's an interface change that might affect applications currently only checking for the "C0h" value for the IPMI OEM sensor types at least comments could be added to the code explaining why the OEM sensor types are overwritten by the "C0h" value.
Reported by: v8kip
Original Ticket: openhpi/bugs/1635