Menu
▾
▴
#72 Sensor list command should use channel field from SDR
Running an "ipmitool sensor list" command on a system where remote sensors are not on channel 0 results in unexpected behavior. The SDR functions were fixed in January of 2009 (lib/ipmi_sdr.c, rev 1.86) to use target I2C addresses and LUNs for non-BMC-owned sensors. Sensors owned by satellite controllers on other channels were read as if they were on channel 0.
I added support for channels in the attached patch. This patch was generated against the 1.8.11 release tree.
Patch to add channel support for remote sensors
Hi,
is there a way how could I replicate this issue?
Thanks.
You'll need a server with a sensor owner on a non-zero (non-IPMB) channel. For instance, an S5520HC server board has several sensors owned by address 0x2C on channel 6.
Otherwise, check the SDRs in your target system. If the owner ID is anything other than 0x20, and the following byte (sensor owner LUN) has a non-zero high nibble, then the sensor is owned externally on a non-IPMB channel, and should be subject to this issue.
Ok, thank you for your reply. I'll check some servers(Oracle/Sun) tomorrow and see if I can find any. I haven't checked your patch yet, as I wanted to gather more info(and doing resp. trying to fix other things).
I meant to find any servers with sensor(s) you've described, so I can reproduce this.
Please, is this what I'm looking for?
> bus=1 mux_addr=0xE0 mux_channel=0x02 slave_addr=0xB8 <
Now, I have tree versions of ipmitool - heavily modified 1.8.10, pure 1.8.11 and CVS. I didn't have any luck with seeing anything different between outputs of these three.
Perhaps servers I have at my disposal doesn't have external sensors as server of yours has.
I'll wait for your reply on my previous inquiry and then commit the changes.
>> > bus=1 mux_addr=0xE0 mux_channel=0x02 slave_addr=0xB8 <
I'm not sure what this is referencing. This could just be an I2C multiplexer on bus 1 (and bus 1 may or may not be channel 0). This also doesn't appear to be in the IPMI SDR format.
If you look at the SDRs for your server, find any type 01 (full) or type 02 (compact) records. In the record key bytes, bits 7:4 of byte 7 (Sensor Onwer LUN) are the channel number. 0b0000 Indicates IPMB. Any other value means that you'll see this issue. Reference IPMI 2.0 Rev 1.0 (Feb 12, 2004) w/markup, table 43-1 and table 43-2 for SDR formats.
>> I didn't have any luck with seeing anything different between outputs of these three.
If, by chance, your target server has the same sensor number on both the IPMB and another channel, they'll both read the same thing. Specifically, they'll both read the value of the sensor on the IPMB. This makes the issue easily missed in some systems.
It is committed in CVS. Can you, please, build ipmitool from CVS and verify it is fixed? And, well, then close this bug.
It looks like revision 1.96 of /lib/ipmi_sdr.c re-introduced (i.e. uncommented) an interface name check. Instead of routing remote sensor requests onto the IPMB, they get routed out to the interface they came in on. This causes all remote sensor requests to fail, no matter which channel they're intended for.
Re-commenting the two lines (i.e. undoing 1.96's change) fixes the issue, but I'll need to figure out a real fix.
I'll find a solution and submit another patch.
This code has been commented out (via #if 0) in version 1.100 so that remote sensors can be read again.
It seems like this got fixed. If it didn't, please, open a new ticket.
Thanks!