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
