Dan, Here is what I can tell you about the test differences between TOB and TOB with my patch applied. For both versions, the interface is opened with the the default IPMB address of 0x20 and not using the address specified on the command line via the -m switch. Another subtle but important point is that with the patch, the interface open will always be done in the main program at the exact same place. With the TOB version, open gets done in a nested fashion due to the fact that any attempt to do an IPMI request prior to open will cause an invocation of open on behalf of the caller.
No Bridging test ./ipmitool/build/src/ipmitool -I lan -H 192.168.1.8 -A none fru In the TOB version, the lan interface open routine is called inside the ipmi_main_intf->sendrecv which is done in ipmi_main to do the the PICMG_GET_PICMG_PROPERTIES_CMD. This open is done using 0x20 as the IPMB address and upon completion, the PICMG discovery code gets an IPMB address of 0x12 and sets this as the default address. The difference in output between the two different ipmitool versions is due to TOB using the PICMG Discovered IPMB address (0x12) to address the IPMB immediately after the first complete open. Using 0x12 yields only two fru records whereas using 0x20 yields 11 fru records. Single Level Bridging Test ./ipmitool/build/src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 fru The open happens the same way as in the prior example, but, because there is a specified target address, another open on the lan interface is attempted and this open is using 0x12 which will cause the Get Channel Authentication Capabilities (0x38) in lan open to time out due to no response. I don't think doing the open a second time was ever the intent. With the patch, 0x20 is for the single open and then 0x82 is used for subsequent bridged requests. Single Level Bridging with a bogus default IPMB address ./ipmitool/build/src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 34 fru In both cases, the open is done with 0x20 and the specified target address (0x82) is used post open for bridging. This is why both get the exact same results. Note that the address 34 is never used because post open all requests are bridged directly to 0x82. For the TOB version 34 will keep the PICMG discovery code from running which is why it doesn't fail like the prior Single Level Bridging Test. With the new code (patched version), there is only a single open in one place in ipmitool which I think is what really should be happening. After all the time spent analyzing these few cases, I'm starting to think it would be good for me to remove all code in sendrecv routines which causes an interface to be automatically opened on the first request. Every time I've run across a case where the open happens in sendrecv, I've seen problems. It's interesting to note that some interfaces don't do a second open if the interface was already opened prior whereas in lan for example it is perfectly happy to try to do the open again. I doubt the lan interface code was really written to support the ability to open the interface multiple times given the fact that there is a single global interface structure. Overall, I think the patch resolves many more issues than it may cause, but we need to do some more testing to feel better about it. I'm still thinking that any specification of a -m address command line option should inhibit PICMG address discover for the primary IPMB and that the specified address should be used for open instead of the default address of 0x20. Does anyone object? If this were done, you would never be able to successfully open an interface if you specify a bogus IPMB address. This took me way to long to figure out what was going on with the TOB version, and I don't really think I have the time to do this for every test case. Thanks, Jim -- Jim Mankovich | jm...@hp.com (US Mountain Time) -- On 4/24/2013 12:27 PM, Dan Gora wrote: > On Wed, Apr 24, 2013 at 12:52 PM, Jim Mankovich <jm...@hp.com> wrote: > >> The first major difference between TOB (What you call CVS ROOT) and TOB plus >> my >> patch is the fact that on a PICMG platform, my patch will always perform a >> PICMG >> address discovery, whereas TOB would only do this if you specified '-m 0'. >> This is >> why you get a different answer for ipmitool fru with my patch vrs TOB and >> also why >> you found TOB would get you the same result as my patch when you specified >> '-m 0' >> with TOB. >> > <rant> > ugh.. This is (just one of many reasons) why I _hate_ CVS. I think > that probably your TOB is different from mine. I just got a patch > committed a few days ago which would default to doing the PICMG addr > discovery if you didn't specify any -m option. That was different > from the 1.8.12 behavior where you had to explicitly specify '-m 0' to > force it to do address discovery. > > If we were using something sensible like 'git' we could talk about > commit SHAs and actually know what we were talking about... > </rant> > >> The other thing you found with my patch is that you can no longer address >> the "Asis ATCA IPMI Shelf Manager". This is due to the change to always do >> PICMG >> discovery of the IPMB address and utilize the discovered address instead of >> having >> -m override the discovered address. With the TOB code, an address >> specified with >> -m or the default IPMB address 0x20 would always be used unless you >> specified '-m 0' >> to force discovery. To fully enable prior functionality, I would have to >> make the >> specification of any address with -m <address> inhibit default PICMG >> discovery. I >> think this is the right thing to do and I'll update my patch to do this >> unless folks have >> any issues with this change. I would also change the man page for -m to >> state the >> following: >> Set the local IPMB address. The default is 0x20 or auto discovered on >> PICMG >> platforms so there should be no need to change it for normal operation. >> >> With the above change, you will be able to address the Shelf Manager again, >> but you >> would have to specify -m 0x20 to do so. > Actually I am still able to access the "Asis ATCA IPMI Shelf Manager" > with your patch both with and without -m 0x20. > >> Now, when you get down to trying to address specific entities via the >> bridging command >> line arguments you will find that certain things just don't get you what you >> would expect unless >> you understand the internal implementation of -m, and the bridging command >> line switches. > Right.. It's very very confusing... > > >> You showed one example when you tried to address 0x28 with the TOB version. >> This fails on >> your system because you didn't specify -m 0 to have ipmitool use the PICMG >> discovered address >> instead of the default 0x20 address. > Nope, the TOB still fails even specifying -m 0. > > dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 0 fru > Error: Unable to establish LAN session > FRU Device Description : Builtin FRU Device (ID 0) > Get Device ID command failed > > dg:speedy:build => src/ipmitool -v -I lan -H 192.168.1.8 -A none -t > 0x82 -m 0 fru > Running PICMG GetDeviceLocator > Discovered PICMG Extension 2.3 > Discovered IPMB address = 0x12 > Get Auth Capabilities command failed > Get Auth Capabilities command failed > Error: Unable to establish LAN session > FRU Device Description : Builtin FRU Device (ID 0) > Get Device ID command failed > >> You should probably verify that when you add '-m 0' to the following command >> line you get >> the same answer as the patched version. Also, you can use -v to see the >> PICMG discovered >> address (which I assume is not 0x20 on your platform). >> > It seems to be the opposite for the TOB. You have to specify any > non-zero -m value to get it to _skip_ the PICMG addr discover to get > it to give the same output when I try and target my APR (ie address > 0x82): > > dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 123 > fru > FRU Device Description : Builtin FRU Device (ID 0) > Board Mfg Date : Thu Sep 20 21:00:00 2012 > Board Mfg : ADAX, Inc. > Board Product : PacketRunner > Board Serial : 0000146 > Board Part Number : 90-4000-00 > Product Manufacturer : ADAX, Inc. > Product Name : PacketRunner > Product Part Number : 000000 > Product Version : MRL 15 > Product Serial : 0000146 > > FRU Device Description : ADAX PR > Board Mfg Date : Thu Sep 20 21:00:00 2012 > Board Mfg : ADAX, Inc. > Board Product : PacketRunner > Board Serial : 0000146 > Board Part Number : 90-4000-00 > Product Manufacturer : ADAX, Inc. > Product Name : PacketRunner > Product Part Number : 000000 > Product Version : MRL 15 > Product Serial : 0000146 > > FRU Device Description : ADAX ATMiv-AMC (ID 3) > Board Mfg Date : Wed Oct 28 14:12:00 2009 > Board Mfg : ADAX > Board Product : ATM4-AMC > Board Serial : 0000354 > Board Part Number : A > Product Manufacturer : ADAX > Product Name : ATM4-AMC > Product Part Number : 82-6000 > Product Version : MRL 6A > Product Serial : 0000354 > Product Asset Tag : COMM > > FRU Device Description : ADAX ATMiv-AMC (ID 4) > Board Mfg Date : Tue Dec 14 14:12:00 2010 > Board Mfg : ADAX > Board Product : ATM4-AMC > Board Serial : 0000289 > Board Part Number : A > Product Manufacturer : ADAX > Product Name : ATM4-AMC > Product Part Number : 82-6000 > Product Version : MRL 7 > Product Serial : 0000289 > Product Asset Tag : COMM > > dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 > -m 0x20 fru > FRU Device Description : Builtin FRU Device (ID 0) > Board Mfg Date : Thu Sep 20 21:00:00 2012 > Board Mfg : ADAX, Inc. > Board Product : PacketRunner > Board Serial : 0000146 > Board Part Number : 90-4000-00 > Product Manufacturer : ADAX, Inc. > Product Name : PacketRunner > Product Part Number : 000000 > Product Version : MRL 15 > Product Serial : 0000146 > > FRU Device Description : ADAX PR > Board Mfg Date : Thu Sep 20 21:00:00 2012 > Board Mfg : ADAX, Inc. > Board Product : PacketRunner > Board Serial : 0000146 > Board Part Number : 90-4000-00 > Product Manufacturer : ADAX, Inc. > Product Name : PacketRunner > Product Part Number : 000000 > Product Version : MRL 15 > Product Serial : 0000146 > > FRU Device Description : ADAX ATMiv-AMC (ID 3) > Board Mfg Date : Wed Oct 28 14:12:00 2009 > Board Mfg : ADAX > Board Product : ATM4-AMC > Board Serial : 0000354 > Board Part Number : A > Product Manufacturer : ADAX > Product Name : ATM4-AMC > Product Part Number : 82-6000 > Product Version : MRL 6A > Product Serial : 0000354 > Product Asset Tag : COMM > > FRU Device Description : ADAX ATMiv-AMC (ID 4) > Board Mfg Date : Tue Dec 14 14:12:00 2010 > Board Mfg : ADAX > Board Product : ATM4-AMC > Board Serial : 0000289 > Board Part Number : A > Product Manufacturer : ADAX > Product Name : ATM4-AMC > Product Part Number : 82-6000 > Product Version : MRL 7 > Product Serial : 0000289 > Product Asset Tag : COMM > > dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 > -m 0x12 fru > FRU Device Description : Builtin FRU Device (ID 0) > Board Mfg Date : Thu Sep 20 21:00:00 2012 > Board Mfg : ADAX, Inc. > Board Product : PacketRunner > Board Serial : 0000146 > Board Part Number : 90-4000-00 > Product Manufacturer : ADAX, Inc. > Product Name : PacketRunner > Product Part Number : 000000 > Product Version : MRL 15 > Product Serial : 0000146 > > FRU Device Description : ADAX PR > Board Mfg Date : Thu Sep 20 21:00:00 2012 > Board Mfg : ADAX, Inc. > Board Product : PacketRunner > Board Serial : 0000146 > Board Part Number : 90-4000-00 > Product Manufacturer : ADAX, Inc. > Product Name : PacketRunner > Product Part Number : 000000 > Product Version : MRL 15 > Product Serial : 0000146 > > FRU Device Description : ADAX ATMiv-AMC (ID 3) > Board Mfg Date : Wed Oct 28 14:12:00 2009 > Board Mfg : ADAX > Board Product : ATM4-AMC > Board Serial : 0000354 > Board Part Number : A > Product Manufacturer : ADAX > Product Name : ATM4-AMC > Product Part Number : 82-6000 > Product Version : MRL 6A > Product Serial : 0000354 > Product Asset Tag : COMM > > FRU Device Description : ADAX ATMiv-AMC (ID 4) > Board Mfg Date : Tue Dec 14 14:12:00 2010 > Board Mfg : ADAX > Board Product : ATM4-AMC > Board Serial : 0000289 > Board Part Number : A > Product Manufacturer : ADAX > Product Name : ATM4-AMC > Product Part Number : 82-6000 > Product Version : MRL 7 > Product Serial : 0000289 > Product Asset Tag : COMM > > > I really don't get this to be honest. > > > All this with the new patch seems to be fine to me. However there are > a couple of things I still don't really understand: > > 1) What do you use double bridging for in a PICMG system? > 2) How (and can you) access AMC cards from an external system manager. > > For example to read the FRU information from my ATM4 AMC card on the > APR I would expect that you'd do something like: > > With Jim's patch > ================ > dg:speedy:build(master) => src/ipmitool -v -I lan -H 192.168.1.8 -A > none -t 0x78 -b 7 -T 0x82 -B 0 fru > Running PICMG GetDeviceLocator > Discovered PICMG Extension 2.3 > Discovered IPMB-0 address = 0x12 > FRU Device Description : Builtin FRU Device (ID 0) > FRU Read failed > FRU Read failed > > TOB > ==== > dg:speedy:build => src/ipmitool -v -I lan -H 192.168.1.8 -A none -t > 0x78 -b 7 -T 0x82 -B 0 fru > Running PICMG GetDeviceLocator > Discovered PICMG Extension 2.3 > Discovered IPMB address = 0x12 > Get Auth Capabilities command failed > Get Auth Capabilities command failed > Error: Unable to establish LAN session > FRU Device Description : Builtin FRU Device (ID 0) > Get Device ID command failed > > Maybe this is just not possible from the external system manager... > > thanks > dan > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
