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. Regarding to the BRIDGE_TO_SENSOR macro, I am now convinced that it should work as needed. There is one more thing. Please, add PICMG Extension 5.0 (05h) for MicroTCA.0 base specification. 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 >>>>>> >>>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ 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
