Re: [Ipmitool-devel] ipmitool bridging on PICMG systems

[Dmitry B. <di...@pi...>]

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... (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... (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... (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... (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...  (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
>>>>>>>>> Ipm...@li...
>>>>>>>>> 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
>>>>>>>> Ipm...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>