Hello, Jim, I need to think it through. Since double bridging is used to access AMC modules, then I guess, it maybe not worth to bother with the discovered PICMG address in LAN or other interfaces.
Regards, Dmitry 24.04.2013 23:42, Jim Mankovich пишет: > Dmitry, > > See below, > > -- Jim Mankovich | jm...@hp.com (US Mountain Time) -- > > On 4/19/2013 12:47 AM, Dmitry Bazhenov wrote: >> Hello, Jim, >> >> Unfortunately, we can not change my_addr after discovering that the >> IPMC address on the primary IPMB is different from what was used to >> connect the IPMC. >> >> Consider an example. A board is accessed via LAN using 20h as a slave >> addres while the slave address on the primary IPMB is 90h. If we set >> my_addr to 90h, all subsequent RMCP packets will be incorrectly >> composed and discarded by the board. >> >> For this case we should set another address value, e.g. my_ipmb_addr, >> which defaults to my_addr but then can be changed via PICMG discovery. > > I agree that the scenario you present above will cause failures for lan > interfaces if it it were to occur, but I don't believe it > would ever make sense for PICMG discovery over lan to return anything > except 20h if the interface were opened using 20h. > > Nothing I did should change the way in which the lan interfaces work > IPMB addressing and PICMG discovery. > > With my changes, the only interface which supports re-setting my_addr to > the IPMB discovered address is OpenIPMI. > >> >> Regarding to the BRIDGE_TO_SENSOR macro, I am now convinced that it >> should work as needed. > Good >> >> There is one more thing. Please, add PICMG Extension 5.0 (05h) for >> MicroTCA.0 base specification. >> > Is this another version like PICMG_AMC_MAJOR_VERSION. If so, should it > be, > PICMG_MICROTCA_MAJOR_VERSION or is something else more appropriate? > >> Regards, >> Dmitry >> >> 18.04.2013 0:01, Jim Mankovich пишет: >>> Hi Dmitry, >>> >>> I've attached an update patch which removes the need to close/re-open >>> the interface when >>> the PICMG discovered IPMB address is found to be different than the IPMB >>> address used to >>> open the interface. A new per interface function was added to enable >>> setting the IPMB >>> address (if the interface supports it), and the OpenIPMI interface was >>> modified to provide this >>> interface. See the patch for details. >>> >>> In putting together the BRIDGE_TO_SENSOR macro, I was working under the >>> assumption that channel >>> 0 was always used to identify the primary IPMB Channel (per the IPMI >>> specification). This >>> is why I first qualify that the SDR sensor record channel is equal to >>> zero before I compare the >>> target_ipmb_addr (which is only set on PICMG platforms), with the SDR >>> sensor record address. >>> This comparison is intended to be true when the sensor is on an IPMB and >>> the target IPMB (as returned >>> by PICMG Get Address Info) matches the sensor address. If this is the >>> case, then this sensor does >>> not require any extra bridging beyond what was used to address the SDR >>> repository (PICMG >>> platforms only). If you would like me to explicitly run time verify >>> in the macro that this condition is PICMG >>> only, I can qualify it with intf->picmg_avail in addition to the >>> target_ipmb_addr test. >>> >>> The second condition in the BRIDGE_TO_SENSOR macro simply looks to see >>> if the sensor record >>> address and channel exactly match the argument specified target address >>> and channel (-t <address> >>> -b <channel>). If this is true, then the sensor does not require any >>> extra bridging beyond what >>> was used to address the SDR repository (any platform). This second >>> condition check doesn't change >>> the current logic from what exists today, it just clarifies the case in >>> which no extra bridging is >>> necessary beyond what was specified on the ipmitool command line. If >>> this test really confuses folks, it >>> could be removed. >>> >>> NOTE: With the code that currently exists today in ipmitool, the address >>> of the sensor from the SDR repository >>> always overwrites the interface target address and target channel prior >>> to accessing the sensor >>> via the interface sendrecv routine. Then in the interface sendrecv >>> routines, bridging requests will be >>> built using the target address (target_addr) and channel >>> (target_channel) if the target_addr doesn't match the >>> interface address (my_addr). >>> >>> I did not intend to change how sensors are addressed via bridging on non >>> PICMG platforms. >>> >>> Thanks in Advance, >>> Jim >>> >>> -- Jim Mankovich | jm...@hp.com (US Mountain Time) -- >>> >>> On 4/16/2013 11:58 PM, Dmitry Bazhenov wrote: >>>> Hello, Jim, >>>> >>>> Please, see my comments mixed in. >>>> >>>> 17.04.2013 2:21, Jim Mankovich пишет: >>>>> Dmitry, >>>>> >>>>> See my comments below. >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> -- Jim Mankovich | jm...@hp.com (US Mountain Time) -- >>>>> >>>>> On 4/15/2013 11:01 PM, Dmitry Bazhenov wrote: >>>>>> 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). >>>>> I did not intended to do anything which would invalidate using >>>>> "correct >>>>> IPMB when establishing or closing session/interface. But, I did need >>>>> to close/re-open to connect to the discovered IPMB address when I ran >>>>> across the issue with OpenIPMI. See my answer to your specific >>>>> question associated with OpenIPMI below. >>>> >>>> Understood. But, still, there is an issue with the Send Message >>>> request when performing bridging or double bridging using the LAN >>>> interfaces. Though, it is a separate issue. >>>> >>>>> >>>>>> >>>>>> 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. >>>>> Using the second acquired address for sensor owner ID comparison for >>>>> bridging was my intent with the change I made. Did you see something >>>>> that indicated this was not what I was doing? Also, the channel >>>>> number has to be used in the comparison as well since it is part of >>>>> addressing identified in the sensor entries in the SDR repository. >>>> >>>> You're right. I have missed it at the first time. >>>> >>>> But still, there are issues with checking if bridging is needed: >>>> >>>> First: in my opinion, the channel comparison is wrong in the >>>> BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC >>>> may not match with the channel number used to access the target IPMC >>>> (intf->target_channel). >>>> >>>> For example, for PICMG-defined Carrier IPMC, the channel for accessing >>>> an AMC module is 7, while for the AMC module, the same channel is 0. >>>> >>>> I understand that it is likely for PICMG systems that the first check >>>> in the macro succeeds and the second check does not really matter. >>>> But I am not sure that there will be no problem with other system >>>> types. >>>> >>>> Second, the target address and channel substitution may be wrong too. >>>> This works only if intf->target_channel can be used to access the >>>> sensor owner, but it may not be the case. So, in some situation, >>>> additional bridging step is needed. If a double bridging is already >>>> used, such sensors may not be even reachable. >>>> >>>> However, I can not imaging systems where such situation is possible. >>>> So, this is rather theoretical issue. >>>> >>>>> >>>>>> 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). >>>>> >>>>> I could certainly do this on non PICMG-based systems, but isn't it >>>>> possible that there could be more than one Management Controller >>>>> Locator >>>>> record in the target SDR repository? If there can be more than one, >>>>> how do you know which one to use? >>>> >>>> There can be several MC locators for non-PICMG systems. PICMG-systems >>>> contain only one MC locator and several FRU Device locators for >>>> subsidiary FRUs. >>>> >>>> I suggest fetching the target_ipmb_addr only for PICMG-based systems. >>>> >>>>> >>>>>> >>>>>> 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. >>>>> The OpenIPMI interface has the ability to set the address vial >>>>> IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid >>>>> the close/re-open. Did your fix to resolve bridging issues work >>>>> correctly with OpenIPMI? >>>> >>>> We do not actively use the OpenIPMI driver, so we are not aware of its >>>> issues. >>>> My point is that no other interface drivers need this additional >>>> close/open. So, it might be worth to do it only for the OpenIPMI >>>> interface. >>>> >>>> No more comments. >>>> >>>> Regards, >>>> Dmitry >>>> >>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
