Folks,
Even though it wasn't important enough to delay the openhpi-2.15
release, I do have a resolution to the issue I found in testing, below.
5) hpiinv returned the FRU data for the baseboard (sa=0x20) instead of
the front panel board (sa=0xc0).
This was an old problem, not something new.
This should have been handled in
ipmi_mc_vendor_intel.cpp/cIpmiMcVendorIntelBmc::ProcessFru by SetAddr().
That code executed as designed, but did not have the desired effect.
Not Important - a pre-existing issue, only on certain platforms
The code seemed to be correct for SetAddr() to change the slave_addr and
for it to be used in reading the FRU, and in fact, when I added code to
log what it was really doing, it did work. With this patch, it works,
with or without logging. Without this patch, it doesn't properly Read
the FRU from sa=0xc0.
Without this logic it would not be possible to root cause the problem
anyway, so I propose that this be added as a patch.
Andy
--- plugins/ipmidirect/ipmi_con_smi.cpp-old 2010-06-30
14:26:36.000000000 -0400
+++ plugins/ipmidirect/ipmi_con_smi.cpp 2010-07-01 08:05:35.000000000
-0400
@@ -327,6 +327,13 @@
req.msgid = r->m_seq;
+ if (send_addr.m_slave_addr != 0x20) {
+ stdlog << "SMI SendCmd: sa=" << send_addr.m_slave_addr <<
+ " chan=" << send_addr.m_channel <<
+ " type=" << send_addr.m_type <<
+ " netfn=" << req.msg.netfn <<
+ " cmd=" << req.msg.cmd << ".\n";
+ }
int rv = ioctl( m_fd, IPMICTL_SEND_COMMAND, &req );
if ( rv )
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
