Hi,
current ipmitool cannot read sensors on the aforementioned HW (and also
DL165 and DL180; DL120 works well). The bug was introduced in version
1.8.11, which enables bridging of sensor readings by default:
struct ipmi_rs *
ipmi_sdr_get_sensor_reading_ipmb(struct ipmi_intf *intf, uint8_t sensor,
uint8_t target, uint8_t lun)
{
/* SNIP */
uint8_t save_addr;
save_addr = intf->target_addr;
intf->target_addr = target;
/* request composition snipped out */
rsp = intf->sendrecv(intf, &req);
intf->target_addr = save_addr;
}
where 'target' and 'lun' are taken directly from SDR (e.g. Owner ID and
Owner LUN in table 43-1 of IPMI 2.0 spec.)
The HP HW returns some sensors as owned by system software with ID '0'
(=BIOS, according to IPMI 2.0 spec, table 5-4), i.e. 'target' = 1, and
the code above tries to bridge the sensor reading from BMC (0x20) to
address 0x1, which fails. Direct reading of the sensor value from the
BMC succeeds. Question is, who is to blame? HP for reporting wrong owner
or ipmitool for trying to bridge the request? The IPMI specification
does not give me any answer (or I am not able to find it there).
What is the correct behavior? It seems the bridging was added there for
a reason, I am just not able to see it.
Jan
------------------------------------------------------------------------------
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk
Collect, index and harness all the fast moving IT data generated by your
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights.
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
