Dmitry, Dan, In doing some testing on my system, I've found that the value of the IPMB address doesn't make any difference when you do bridged requests over lanplus. I believe the same is true for lan as well since Dan's testing showed that the value specified with -m address didn't make any difference in success or failure when used in conjunction with a target address (-t). This is not the case when not doing bridging.
-- Jim Mankovich | jm...@hp.com (US Mountain Time) -- On 4/25/2013 7:24 AM, Dmitry Bazhenov wrote: > 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
