Jim, Dmitry,
You are getting into a gray area of IPMI. SDR's allow a single channel but
IPM Controllers allows multiple IPMI Buses, each with their own channel.
Management Controller Locator Record do not have a provision for which IPMI
channel is perfered or active(in the case where there are redundant IPMB
buses which are not the round robin PICMG IPMI-A, IPMI-B on a single
channel).
I don't know how you are going to resolve this without using information
that is vendor specific. But there might be a way.
If you come up with an answer, I'll be happy to add it to our ipmitool
equivalent that is in Java(Our Hemi software).
Hank Bruning
JBlade
On Tue, Apr 16, 2013 at 4:21 PM, Jim Mankovich <jm...@hp.com> wrote:
> 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.
>
> >
> > 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.
>
> > 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?
>
> >
> > 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?
> > 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
>
------------------------------------------------------------------------------
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
