Hello, Jim, Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use correct IPMB address when establishing or closing session/interface. This especially regards to LAN and LAN+ drivers. Since some library functionality may close and re-open the interface during its work (as does HPM.1), this may cause problems. Also, a correct address must be used for bridging (when composing a Send Message request). In logical part, when bridging is used, we must perform the address retrieval procedure not only on the IPMC on which the interface was opened, but on the target IPMC as well. And the second acquired address must be used in sensor owner ID comparison to decide if bridging is required or not. It might be, if double bridging is used to access the target IPMC, that sensor values are unreachable. Also, since not all IPMCs are PICMG-based, it maybe not correct to use the Get Address Info command for the target IPMC address retrieval. It is better to fetch the Management Controller Locator record instead (implement this retrieval in ipmi_sdr.c or ipmi_sensor.c). And regarding to the OpenIPMI interface driver. Is it possible to set another IPMC address without closing and re-opening interface? Other interface drivers seem not require such procedure. Regards, Dmitry 15.04.2013 23:12, Jim Mankovich пишет: > Hi Dmitry, > > I have a similar approach to what you outlined, but I did not find the > need to do > anything different the the "-m" command line switch. I've attached a > patch I've > been using to resolve the issue I was having and would appreciate any > feedback you > might have on my approach. The patch is for the CVS ipmitool source > code at TOB > this morning. > > I changed ipmi_main() to always open the interface using either 0x20 or > the address > specified with the "-m" switch. With the code as it exists today, open > is sometimes > done in main and sometimes done when the first IPMI request is made. > I found the > defer of the open quire problematic, so I changed the code to always do > the open prior > to the first IPMI request. After the initial open, I use the PICMG > get address info to > get the IPMB-0 address. If I was able to discover an address, I close > and re-open > the interface with the discovered IPMB-0 address as I found this was > necessary to make > sure that the open ipmi driver had the correct address of the target > IPMB-0. Then, if bridging is > specified with "-t" and/or "-T", I get the bridge target IPMB-0 address > and store that away to > determine when bridging is necessary for sensors identified in the SDR > repository accessed via > the bridging command line arguments. > > Thanks, > Jim > > -- Jim Mankovich | jm...@hp.com (US Mountain Time) -- > > On 4/15/2013 9:05 AM, Dmitry Bazhenov wrote: >> Hello, Jim, >> >> Your understanding is correct. Moreover, we already have a patch which >> solves the issue (in our local IPMITool repo). We are going to submit >> the patch for this issue shortly. >> >> And to the topic raised. >> >> The sensor owner ID in the SDR in my opinion shall match with the IPMC >> slave address on the primary IPMB bus (channel #0). >> >> Since there are cases when the IPMC accessed from other channels (than >> channel #0), like LAN, the slave address of the IPMC on that channel may >> not match with the primary IPMB address. >> >> We solved this problem as follows: >> - introduced a BMC address which can be overridden by "-m" command-line >> parameter (default valuse is 20h). This address is used to access the >> IPMC on which a session to establish a session (for LAN). >> - then using Get PICMG Properties to check whether the board is a >> PICMG-based system. >> - use either Get Address Info for FRU #0 or fetch the Management >> Controller Locator Record to query the IPMC slave address on the primary >> IPMB. >> - store the fetched slave address. it then used to match the sensor >> owner ID to decide if the bridging to sensor is required on not. >> - for the case when bridging is used, the stored slave address is used >> to compose the Send Message command is return address. >> >> Regards, >> Dmitry >> >> 15.04.2013 20:47, Jim Mankovich пишет: >>> All, >>> >>> I've been digging into various issue associated with ipmitool bridging >>> on a PICMG >>> >>> system and I wouldappreciate some help with understanding what the >>> actual intended >>> >>> use of the bridging command line arguments was. There are two >>> different bridging >>> >>> argument specifications, -t target_address/-b target_channel (single >>> bridge), and >>> >>> -T transit_address/-B transit_channel (dual bridge). >>> >>> When only -t is specified, single level bridging will be used to read >>> the SDR repository >>> >>> if the address specified by -t is not equivalent to the ipmitool >>> identified IPMB-0 address. >>> >>> Note: The ipmitool identified IPMB-0 address is either the default of >>> 0x20, or specified >>> >>> on the command line via the -m address switch, or discovered via PICMG >>> get address >>> >>> info. >>> >>> In addition to -t, you may also specify a transit address via -T.If a >>> transit address is >>> >>> specified, dual bridging will be used to read the SDR repository(via the >>> transit address >>> >>> to get to the target identified via -t). The specification of a >>> transit address without a >>> >>> target address is meaningless as the transit address is not used unless >>> there is a target >>> >>> address specification with -t. >>> >>> Does my description agree with your understanding of these switches and >>> their use? >>> >>> Now, in addition to bridging to read the SDR repository, bridging will >>> also occur to access >>> >>> an individual sensor if the sensor owner id identified in the SDR >>> repository does not match >>> >>> the ipmitool identified IPMB-0 address. This bridging will override >>> the specified target address >>> >>> identified via the -t switch, but will make use of the transit address >>> (and dual bridge) when >>> >>> both -t and -T are specified. >>> >>> This bridging implementation has issues on the PICMG system I have been >>> using when >>> >>> addressing sensors whose owner id and channel specification in the SDR >>> repository do >>> >>> not identify the exact same addressing that was used to read the SDR >>> repository. >>> >>> For example:If a sensor identified in an SDR repository resides on >>> IPMB-0 (channel 0), >>> >>> but the SDR repository was accessed via bridging on IPMB-L (channel 7), >>> the sensor can't >>> >>> be accessed with the current code because the sensor will be addressed >>> via bridging using >>> >>> channel 0 (from the SDR repository)instead of channel 7 (from the -b >>> channel specification). >>> >>> The problem is that when using bridging to access an SDR repository, the >>> bridged SDR >>> >>> repository destination may actually identify another IPMB-0 at the >>> bridged destination. >>> >>> If this is the case, then the sensor can simply be read using the same >>> bridging as was >>> >>> used to read the SDR repository. >>> >>> On PICMG compliant systems, this issue can be resolved by getting the >>> IPMB-0 address >>> >>> of the target and compare this target IPMB-0 address with the sensor >>> owner id/channel >>> >>> number from the SDR repository.If the sensor owner id is equal to the >>> target IPMB-0 >>> >>> address and the sensor channel is 0, then the sensor can be accessed >>> using the same >>> >>> addressing as was used to address the SDR repository. >>> >>> >>> I have some ipmitool changes in the works which resolve the sensor >>> bridging issue >>> I've described, but I need some insight from someone more familiar with >>> PICMG and >>> sensor bridging to make sure my analysis of the problem I'm seeing is >>> correct. >>> >>> Thanks in advance, >>> Jim >>> >>> -- >>> -- Jim Mankovich |jm...@hp.com (US Mountain Time) -- >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Precog is a next-generation analytics platform capable of advanced >>> analytics on semi-structured data. The platform includes APIs for >>> building >>> apps and a phenomenal toolset for data science. Developers can use >>> our toolset for easy data analysis & visualization. Get a free account! >>> http://www2.precog.com/precogplatform/slashdotnewsletter >>> >>> >>> >>> _______________________________________________ >>> Ipmitool-devel mailing list >>> Ipmitool-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel >>> >> ------------------------------------------------------------------------------ >> >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for >> building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> Ipmitool-devel mailing list >> Ipmitool-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel >> >> > ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
