Al, That's not what the old method did, as I understand it, it just inserted the given slave address in the KCS command (system interface), rather than bridging it via IPMB (encapsulating it inside a SendMessage/GetMessage sequence). The slave address was still used. The pre-1.8.10 code worked well for most users (bladed or other servers), but there were some cases that apparently needed bridging. Bernard would have to explain which cases those are. The new bridging method is the odd case, so it should be the option, IMO.
Note that the OpenIPMI driver also uses SendMessage/GetMessage internally, and that could be complicating things. Andy -----Original Message----- From: Al Chu [mailto:ch...@llnl.gov] Sent: Wednesday, February 03, 2010 2:21 PM To: Andy Cress Cc: Jan Safranek; Francois Isabelle; ipmitool-devel@lists.sourceforge.net Subject: Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server Hey Andy, Your comments made me think of something. I believe the only other piece of information (besides the slave address in the packet header) that determines what sensor is read is the sensor number. Sensor numbers can be duplicated per owner id. So if you simply assume the owner to be the BMC (even if the owner id is different in the SDR), isn't it possible you are reading a different sensor entirely?? How can you be sure if you're reading the right sensor reading?? It doesn't sound like something that should be the default case. Al On Wed, 2010-02-03 at 10:59 -0800, Andy Cress wrote: > IMO, the old non-bridged behavior should be the default, and the new > bridged behavior should require the command-line option, for two > reasons: > 1) Back-compatible with older ipmitool versions > 2) There are probably more cases using non-bridged than using bridged. > Unless Bernard Manjou can argue otherwise? > > Andy > > -----Original Message----- > From: Jan Safranek [mailto:jsafr...@redhat.com] > Sent: Wednesday, February 03, 2010 10:21 AM > To: Francois Isabelle > Cc: ipmitool-devel@lists.sourceforge.net > Subject: Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server > > Hi, > > I've got many reports from customers that ipmitool 1.8.11 is not reading > sensors on their HW, while the older version was working - see quoted > mails below. > > Now I really need to fix it. In [1] you mention "I think that we might > generalise the 'PICMG extension' tweak already in the OpenIPMI plugin" - > can you please elaborate on that? I am willing to help with the code, if > someone explains me what needs to be done. > > [1]: > http://*sourceforge.net/mailarchive/forum.php?thread_name=C2866F9FC4CB034EB51A633DF16859860553CE1E%40ssbarcelone.teknor.com&forum_name=ipmitool-devel > > So far I got an idea to disable bridging by command line option (let's > say '-n') and sending all requests to BMC (i.e. using > IPMI_SYSTEM_INTERFACE_ADDR_TYPE and IPMI_BMC_CHANNEL), like it was in > the old and working version. Of course, the option would work in > plugins/open interface, lan and lanplus would work as they are now. > > What do you say? Is '-n' acceptable solution? > > Thanks in advance > > Jan > > On 06/01/2009 04:44 PM, Isabelle, Francois wrote: > > See: > > > > http://*sourceforge.net/mailarchive/forum.php?thread_name=C2866F9FC4CB034EB51A633DF16859860553CE1E%40ssbarcelone.teknor.com&forum_name=ipmitool-devel > > > > > > In a blade server, your IPMC might be a satellite as well. I think, there > > is indeed a problem with IPMITOOL due the IPMI spec requiring the IOL > > address to be 0x20. > > > > Are you using IOL ? Otherwise try ipmitool -m<source> -t<target> sensor > > list > > > > > > François Isabelle | Software Designer | Kontron Canada | T 450 437 5682 |F > > 450 437 8053 | E francois.isabe...@ca.kontron.com > > > > > > > > -----Message d'origine----- > > De : Jan Safranek [mailto:jsafr...@redhat.com] > > Envoyé : 1 juin 2009 09:56 > > À : ipmitool-devel@lists.sourceforge.net > > Objet : [Ipmitool-devel] Broken sensors on Dell 1855 blade server > > > > ipmitool-1.8.11 does not display sensor threshold on Dell 1855 blade server: > > > > # ipmitool sensor list > > Mem Temp 2 | na | degrees C | na | na | na > > | na | na | na | na > > > > With older version (ipmitool-1.8.9), I can get some values: > > # ipmitool sensor list > > > > Mem Temp 2 | na | degrees C | ok | na | 5.000 | > > 10.000 | 75.000 | 80.000 | na > > > > > > I dug into sources and I have found out, that sensor readings were > > modified in CVS version 1.33 of lib/ipmi_sensors.c. There are many > > similar changes like: > > > > -rsp = ipmi_sdr_get_sensor_thresholds(intf, sensor->keys.sensor_num); > > +rsp = ipmi_sdr_get_sensor_thresholds(intf, sensor->keys.sensor_num, > > + sensor->keys.owner_id, sensor->keys.lun); > > > > > > and in ipmi_sdr_get_sensor_thresholds(): > > > > + save_addr = intf->target_addr; > > + intf->target_addr = target; > > ...send the message... > > + intf->target_addr = save_addr; > > > > This causes that the messages requesting thresholds are sent to slave > > address "c0" (addr_type == IPMI_IPMB_ADDR_TYPE), instead to BMC > > directly. Using '-vvv' option prints "Sending request to IPMB target @ > > 0xc0" and some errors like "Error reading event status for sensor #07: > > Invalid command". > > > > The old working ipmitool version sends all messages to BMC (i.e. > > addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE) and it shows correct > > thresholds + event states. > > > > Why was the code changed? CVS log message says "Bernard Manjou 6/10/08 > > patch to include I2c address and LUN so sensors are correctly managed; > > updated by BM for v1.8.10", but I have not found much details on the > > mailing list. Is the described behavior caused by Dell 1855 weirdness or > > is the ipmitool code wrong? I admit I got lost in IPMI 2.0 specification :) > > > > Jan > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side developers& brand creativity professionals. > > Meet > > the minds behind Google Creative Lab, Visual Complexity, Processing,& > > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > > Group, R/GA,& Big Spaceship. http://*p.sf.net/sfu/creativitycat-com > > _______________________________________________ > > Ipmitool-devel mailing list > > Ipmitool-devel@lists.sourceforge.net > > https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side developers& brand creativity professionals. > > Meet > > the minds behind Google Creative Lab, Visual Complexity, Processing,& > > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > > Group, R/GA,& Big Spaceship. http://*p.sf.net/sfu/creativitycat-com > > _______________________________________________ > > Ipmitool-devel mailing list > > Ipmitool-devel@lists.sourceforge.net > > https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://*p.sf.net/sfu/theplanet-com > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel > e...@lists.sourceforge.net > https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://*p.sf.net/sfu/theplanet-com > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
