Hi Michael,

I have a motherboard that lists the device 0 FRU entry in a management
controller record.  So with your patch, the same entry is output twice.

FRU Device Description : Builtin FRU Device (ID 0)
 Board Mfg Date        : Sun Mar 15 10:03:00 2009
 Board Mfg             : DELL
 Board Product         : PowerEdge R610                
 Board Serial          : CN697029390404
 Board Part Number     : 0K399HA01

FRU Device Description : iDRAC6          
 Board Mfg Date        : Sun Mar 15 10:03:00 2009
 Board Mfg             : DELL
 Board Product         : PowerEdge R610                
 Board Serial          : CN697029390404
 Board Part Number     : 0K399HA01

The only difference is the device description is given the name from the
SDR entry.

Al

On Tue, 2012-05-01 at 11:27 -0700, Michael L. Winiarski wrote:
> All,
> 
> I would like to request a code review of this before I submit it to the 
> CVS repository. This has had an initial internal review (by Jim 
> Mankovich). I would like to plan to submit this by May 15, 2012.
> 
> The issue that this patch addresses is when the platform supports 
> satellite controller, the fru print does not check for management 
> controllers. By not checking for management controllers, the fru print 
> will not print any of the fru inventory for the satellite controllers.
> 
> The patch will now check for the FRU Inventory Device bit in the 
> relevant structure (either from the Get Device ID, or from a Mgmt Ctlr 
> SDR) before trying to issue commands [to FRU #0 LUN 0]. The change 
> ensures that fru info for the BMC can be printed (do a BMC GET DEVICE ID 
> and check if FRU Inventory is set). Subsequently, when the SDRs are 
> being walked, it will specifically look for management controller 
> records (in addition to the fru device records). When MC records are 
> found, the FRU Inventory bit is checked to see if fru data should be 
> obtained from that controller. Comments in the code should explain 
> what's being done.
> 
> During internal code review, memory leaks were found, and the code was 
> fixed to plug those.
> 
> The following sections of the IPMI V2.0 spec(March 2009 errata markup) 
> were consulted when developing the fix: 20.1, 33.4, 43.8, and 43.9.
> 
> This was tested on several HP ProLiant models using different levels of 
> verbosity.
> 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to