I believe the problem is that the IPMI driver doesn't know the proper slave (IPMB) address for the local system. The SDR describing the sensor says "0xc0" as the destination address for the sensor, so ipmitool is going to try to send it there. The IPMI driver will intercept those and send them to the local BMC if it knows the slave address, but in many cases it has no way to discover it and assumes it is the default (0x20).
I believe you can use the -m option to ipmitool to override the address. Note that the OpenIPMI library sends the PICMG messages to attempt to determine the IPMB address and sets it automatically. Perhaps this needs to be added to ipmitool. You can also change it in the IPMI driver and I believe that will work, too. Doing this requires writing a little software to call the ioctl to do this, or writing a little script. The script is harder than it should be, you have to hot remove the device and hot add it with a different address. The address information is at /proc/ipmi/0/params. Mine looks like: i2:~# cat /proc/ipmi/0/params kcs,i/o,0xca2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=32 To remove the device, do: i2:~# echo "remove,kcs,i/o,0xca2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=32" >/sys/module/ipmi_si/parameters/hotmod substituting your information for the above, obviously. Then re-add it with the proper ipmb: i2:~# echo "add,kcs,i/o,0xca2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=0xc0" >/sys/module/ipmi_si/parameters/hotmod Now the IPMB address has changed: i2:~# cat /proc/ipmi/0/params kcs,i/o,0xca2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=192 Note this only works with kcs/bt/smic. The procedure for serial ones is similar, but you need to use the serial driver hotmod location in /sys/module/ipmi_serial/parameters/hotmod. -corey Andy Cress wrote: > 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 >>> ------------------------------------------------------------------------------ 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
