Open neo125874 opened 1 year ago
How the sensors are configured is entirely up to the company who did the motherboard design.
It appears, in this case, that the motherboard has a physical temperature sensor for each group of DIMM slots, rather than for each slot, which makes sense. In any case, ipmiutil and similar tools merely read the sensors that the manufacturer has supplied. There is no way for ipmiutil to change that.
thanks for response,
but we got 8 temperature from supermicro's ipmi tool, ipmi-util got A-D & E-H only 2 temperature on the same board. any way to compile different ipmi-util could get this work? (like define metacommand to compile?)
So it sounds like SuperMicro has a custom/non-standard way to combine 4 sensor readings into one sensor. Weird. Why in the world would they do that, when including them as discreet sensors would be easier and better?
If Supermicro's tool can pull 4 separate sensor readings from the same sensor, then so can we, but the hard part is to figure out how, and this would have to be a one-off special case for this vendor/board combo. With some evidence, I may be able to figure out how they combined the readings. What I need is: 1) the output of 'ipmiutil sensor -x' which will show the vendor/motherboard id, and the raw sensor data. 2) the output of the Supermicro tool for the same system for comparison.
the supermicro smc-ipmi-tool display
and the ipmi-util got these dimm temperature value
it's ipmi-util sensor -x to a txt file cmd_log.txt
Hmmm. I had hoped that the SDR record would have some extra fields that would have something new to show that it was a multi-combo sensor. It doesn't.
Note that the standard IPMI GetSensorReading does get the first sensor and it matches what SuperMicro returns. However, the SDR record does not have any extra data to go on. Since the GetSensorReading could in theory work with several sensor numbers on the same SDR, I hoped that there would be some indication in the SDR of the extra sensor numbers, but not so. To get this, SuperMicro has done something proprietary and hidden.
Three alternatives:
1) get a network packet trace of the SMCIPMITOOL.exe run to see what they are doing
2) get SuperMicro to document what they are doing for these DIMM sensor readings (vendor=10876 prod=7054)
3) leave it alone and utilize the first sensor of each.
further question, these 2 sensor values might be from the motherboard, instead of from the ram itself? and if there are 8 temperatures for 8 rams, it might be read from ram's sensor not dimm slot?
dimm == ram. Yes, the sensors are from the motherboard. This is a custom firmware implementation by SuperMicro, which could easily have been implemented by them to IPMI standards instead.
could it get the temperature like: dimm a: 21 dimm b: 23 ... dimm e: 32 dimm f: 33 ...
because now get sensor list include dimm temperature are: dimmABCD: 25 dimmEFGH: 32
any suggestion would be appreciated