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
