Corey wrote: >ipmitool will need modifications to handle it, though I am not sure about the required modification. As specified, this is working just fine now. As you mention, a lot of functionality is handle by FRU 0 but as you mentioned also, the upgrade commands are only available directly. This is a major feature and probably *THE* main reason for this dual bridge implementation. This is a strong requirement from our customer.
Corey wrote: >IMHO, this should work as something "special" in ipmitool. I don't agree that this should be set as something special. What is the problem of leaving that as standard (without any special compiling switch I suppose?). Regards, Jean-Michel Audet -----Message d'origine----- De : Corey Minyard [mailto:[EMAIL PROTECTED] Envoyé : Wednesday, September 12, 2007 2:15 PM À : Audet, Jean-Michel Cc : Dmitry Frolov; Ipmitool-devel@lists.sourceforge.net Objet : Re: [Ipmitool-devel] TR: dual bridge support Ah, ok, this makes sense. Yes, no driver changes should be necessary. ipmitool will need modifications to handle it, though. IMHO, this should work as something "special" in ipmitool. Normally in the AMC case all the sensors and entities of the AMC are front-ended by the IPMC, so there is no need in the normal case to talk directly to the AMC. However, there are special things that need to be done (upgrade, custom control, etc.) that would benefit from this. -corey Audet, Jean-Michel wrote: > Not sure I understand correctly the private and native. This is currently > working without any modification or support from the driver side. We just > add a layer of send message and wait for multiple answers. > > Let me know! > Jean-Michel Audet > > > > > -----Message d'origine----- > De : Dmitry Frolov [mailto:[EMAIL PROTECTED] > Envoyé : Wednesday, September 12, 2007 10:47 AM > À : Audet, Jean-Michel > Cc : Ipmitool-devel@lists.sourceforge.net > Objet : Re: [Ipmitool-devel] TR: dual bridge support > > * Audet, Jean-Michel <[EMAIL PROTECTED]> [12.09.2007 21:25]: > > >> Hi Dmitry and Corey, >> Looks like some of you are trying to get in touch with me!! >> Sorry, I miss the e-mail or I never received it... Anyway, do you still >> have problem with the dual bridge option. >> >> The DUAL bridge option with RMCP+ is used to send a remote command to >> the shelf-manager, bridge it to a ATCA blade and double-bride it to an >> AMC. >> > > Hi, Jean-Michel! > > It used struct ipmi_ipmb_addr fields that are present only in ipmitool's > private ipmi.h but not in native openipmi header. This caused problems > when building with native openipmi headers installed. I added a check > to configure if these fields are present in used header file and it > seems to work. > > It looks like this feature needs in-band driver support, so I'm > interesed in status of this feature in openipmi - is it a proprietary > extension and will it be integrated in openipmi? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
