Corey, After further review :-), Michael and I discovered that the key difference is that this case with IMM did not have a FRU locator record for the baseboard FRU (at fru device id 0), however the FRU data at device id 0 was there, as is required by the IPMI spec, and it works fine.
The root cause is an oversight in the FRU/SDR settings on that box from the factory. However, that doesn't help the case with the installed set of systems. The anomaly can be worked around in the library by attempting to load fru data from the default (sa=0x20, fruid=0) if it hasn't been found in the SDR locators. Putting in a wart specific to this system board wouldn't work because there are several configurations of the system board with/without IMM. Andy -----Original Message----- From: Corey Minyard [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 4:01 PM To: Cress, Andrew R Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Openipmi-developer] FRU dev id on IMM Module It's not necessarily the case that OpenIPMI is wrong (though it is possible). The algorithm for entity presence is complicated and subtle and subject to interpretation in places. If you want a headache, you can read about it in section 40 of the IPMI 2.0 spec. I'd have to spend some time looking at this, and there is one outstanding issue I am working with entity presence detection, but I'm waiting for someone to try to figure out what is right. The patch is attached (for OpenIPMI 2.0.10), but I'm not sure if it will go in or go in as-is. -Corey Cress, Andrew R wrote: > Michael, > > Entity 7.2 is not representing the true picture from an IPMI > perspective. That's the bug. You can see from the fruconfig output > that there is a "Basebrd Mgmt Ctlr" at SlaveAddr/Channel 20/00 with a > fru device id 0. So, the IMM is/does return the right data, if the > software actually reads fru device id 0. > > Keep in mind that the IMM is a plugin BMC daughter card, and so it is a > separate replaceable part, so it must have a separate FRU inventory > record from the baseboard. However, it serves as the MC for the > baseboard when it is installed. > Entity 7.1 (IMM FRU) is not what you want, but entity 7.2 should contain > the baseboard data that is returned by the IMM for fru device id 0. > > The upshot is that the BMC firmware is correct, but the OpenIPMI library > code (version ??) isn't building entity 7.2 correctly, which can be seen > in the differences between running fruconfig/ipmiutil and ipmi_ui. You > may want to leverage the fruconfig.c code from http://ipmiutil.sf.net, > which can run on the OpenIPMI driver as well. Or, there may be a fix > for this in a later OpenIPMI library version (?). > > Andy > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, January 22, 2007 6:34 PM > To: Cress, Andrew R; [email protected] > Subject: RE: [Openipmi-developer] FRU dev id on IMM Module > > Yes, we are adding some information to the baseboard FRU. We would want > it to be updated on the baseboard. > > On Jarrell boards, OpenIPMI returns the following entities (complete > list on earlier email): > 7.1 (IMM Module FRU) fru present > 7.2 (system_board) unknown not present > On the older boards we have: > 7.1 (Basbrd Mgmt Ctlr) mc present > > Since 7.2 says unknown, not present. We're assuming 7.1 will always > represent the baseboard mc (device id = 0; which we know now is not). > Actually the list does not contain an entity classified as mc (unlike in > the old system). > > Is the mini-BMC associated to an entity? > > Also because these are the only entities returned, we use this entity > (7.1) to retrieve/update the fru infomation (during system setup). On > boot, we look at this fru info, to determine which system config file to > load. > > ipmiutil is not part of our RedHat install. Just installed an rpm for > that and will look into this. Thanks. > > Michael > > ---- Original message ---- > >> Date: Mon, 22 Jan 2007 17:16:01 -0500 >> From: "Cress, Andrew R" <[EMAIL PROTECTED]> >> Subject: RE: [Openipmi-developer] FRU dev id on IMM Module >> To: <[EMAIL PROTECTED]>, <[email protected]> >> >> Sure, to find the MC dev id you just read the SDR IPMB MC Locator >> > record > >> (shown on the second line of the fruconfig output) to get the IMM FRU >> information. >> >> However, loading the FRU information from fru device id 0 WILL still >> give you the baseboard FRU information. So, reading FRU data from >> FruDeviceId 0 will still work fine, in all IPMI systems, and that is >> > the > >> last section of the output I attached. >> >> The baseboard is where all of the devices and sensors connect, so most >> likely that is really what you want to do anyway. Is that what you >> meant by FRU updates and appropriate FRU entries? You don't really use >> the IMM FRU entries except as inventory for that plugin card. >> >> Andy >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Monday, January 22, 2007 5:05 PM >> To: Cress, Andrew R; [email protected] >> Subject: RE: [Openipmi-developer] FRU dev id on IMM Module >> >> Andy, >> >> Thanks for the clarification. >> >> Wouldn't this configuration pose as a problem: FRU updates are done to >> the active bmc, w/c is device id 1; yet on bootup, we expect it to be >> > at > >> device id 0. >> >> Anyway, to retrive the active bmc device id? Or to determine that the >> mini-bmc is overriden? >> >> The code is used on both type of machines, I have to be able to >> programmatically detect which device id is actually active and retrieve >> the appropraite FRU entries. Thanks. >> >> Michael, >> >> On the Jarrell motherboard where the IMM resides, there is a default >> mini-BMC and then the IMM plugin with IPMI 2.0 and the advanced >> features. So, there are actually two BMCs, but only one is active at a >> time. That is why the IMM has a FRU Device ID of 1, since the mini-BMC >> occupied FRU ID 0. >> >> This should not pose a problem, and attached is the output from >> 'fruconfig' (from ipmiutil) on a TIGI2U system with an IMM. You can >> > see > >from the attached immfru.txt that the SlaveAddress/ChannelNumber for > the > >> IMM BMC is 20/00, while the SlaveAddress/FruDeviceID is 20/01. >> >> The IPMI 1.5 text you reference is similar to text in section 37.7 >> > about > >> the FRU Device ID, and is still true, since the mini-BMC on that >> motherboard is FRU Device ID 0, but it is inactive. >> >> Andy >> > > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V > _______________________________________________ > Openipmi-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openipmi-developer > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
