If we can tell from the firmware version (device ID), or there is some easy way to tell from the SDRs + device id, we can put a wart in just for the systems that have a problem. There's hooks where you can add things in both places.
-Corey Cress, Andrew R wrote: > 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
