ipmitool-devel

[Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

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

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Isabelle, F. <Fra...@ca...>]

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 fra...@ca...
 


-----Message d'origine-----
De : Jan Safranek [mailto:jsa...@re...] 
Envoyé : 1 juin 2009 09:56
À : ipm...@li...
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
Ipm...@li...
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

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

I have no idea what is IOL, but 'ipmitool -m 0xc0 -t 0xc0 sensor list' 
shows the sensors. Now how to fix it?

Jan

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

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 fra...@ca...
>
>
>
> -----Message d'origine-----
> De : Jan Safranek [mailto:jsa...@re...]
> Envoyé : 1 juin 2009 09:56
> À : ipm...@li...
> 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
> Ipm...@li...
> 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
> Ipm...@li...
> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Al C. <ch...@ll...>]

As an aside on this conversation, has Dell chimed in at any point with
an opinion on this?

I'm not quite understanding what a "satellite MC" here is, but I'm
assuming it's a blade manager, who is supposed to auto-magically route
IPMI commands around to individual blades??  If sensors aren't being
bridged properly, it seems like there is a bug in the "satellite MC"??

I understand that there should be something in place to ensure ipmitool
can work.  I just wanted to comment that this shouldn't be viewed as a
good/right long term solution.

Al

On Wed, 2010-02-03 at 16:20 +0100, Jan Safranek wrote:
> 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 fra...@ca...
> >
> >
> >
> > -----Message d'origine-----
> > De : Jan Safranek [mailto:jsa...@re...]
> > Envoyé : 1 juin 2009 09:56
> > À : ipm...@li...
> > 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
> > Ipm...@li...
> > 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
> > Ipm...@li...
> > 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
> Ipm...@li...
> https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel
> 
-- 
Albert Chu
ch...@ll...
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Andy C. <and...@us...>]

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:jsa...@re...] 
Sent: Wednesday, February 03, 2010 10:21 AM
To: Francois Isabelle
Cc: ipm...@li...
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 fra...@ca...
>
>
>
> -----Message d'origine-----
> De : Jan Safranek [mailto:jsa...@re...]
> Envoyé : 1 juin 2009 09:56
> À : ipm...@li...
> 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
> Ipm...@li...
> 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
> Ipm...@li...
> 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
Ipm...@li...
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
ev...@li...
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Al C. <ch...@ll...>]

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:jsa...@re...] 
> Sent: Wednesday, February 03, 2010 10:21 AM
> To: Francois Isabelle
> Cc: ipm...@li...
> 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 fra...@ca...
> >
> >
> >
> > -----Message d'origine-----
> > De : Jan Safranek [mailto:jsa...@re...]
> > Envoyé : 1 juin 2009 09:56
> > À : ipm...@li...
> > 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
> > Ipm...@li...
> > 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
> > Ipm...@li...
> > 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
> Ipm...@li...
> https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel
> ev...@li...
> 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
> Ipm...@li...
> https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel
> 
-- 
Albert Chu
ch...@ll...
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Andy C. <and...@us...>]

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...@ll...] 
Sent: Wednesday, February 03, 2010 2:21 PM
To: Andy Cress
Cc: Jan Safranek; Francois Isabelle; ipm...@li...
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:jsa...@re...] 
> Sent: Wednesday, February 03, 2010 10:21 AM
> To: Francois Isabelle
> Cc: ipm...@li...
> 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 fra...@ca...
> >
> >
> >
> > -----Message d'origine-----
> > De : Jan Safranek [mailto:jsa...@re...]
> > Envoyé : 1 juin 2009 09:56
> > À : ipm...@li...
> > 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
> > Ipm...@li...
> > 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
> > Ipm...@li...
> > 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
> Ipm...@li...
> https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel
> ev...@li...
> 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
> Ipm...@li...
> https://*lists.sourceforge.net/lists/listinfo/ipmitool-devel
> 
-- 
Albert Chu
ch...@ll...
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Corey M. <mi...@ac...>]

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...@ll...] 
> Sent: Wednesday, February 03, 2010 2:21 PM
> To: Andy Cress
> Cc: Jan Safranek; Francois Isabelle; ipm...@li...
> 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:jsa...@re...] 
>> Sent: Wednesday, February 03, 2010 10:21 AM
>> To: Francois Isabelle
>> Cc: ipm...@li...
>> 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 fra...@ca...
>>>
>>>
>>>
>>> -----Message d'origine-----
>>> De : Jan Safranek [mailto:jsa...@re...]
>>> Envoyé : 1 juin 2009 09:56
>>> À : ipm...@li...
>>> 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
>>>       

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

On 02/04/2010 12:09 AM, Corey Minyard wrote:
> 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

hmmm, mine *already is*:
kcs,i/o,0xca8,rsp=4,rsi=1,rsh=0,irq=0,ipmb=194
(194 = 0xc2)

I have not changed anything, just service ipmi start. I admit I don't 
know how the kernel driver works and how it's configured - how did it 
detect it's not 0x20? I use internal RHEL 5-like kernel and to be 
honest, I don't know what OpenIPMI driver is there :( I might try 
vanilla one if it helps you debug things.

When getting SDR (using IPMI_SYSTEM_INTERFACE_ADDR_TYPE), SDR record 
tells me the owner of the sensor is 0xc2 (sensor->keys.owner_id), i.e. 
if I understand it correctly, it points to itself.

But ipmitool thinks the local IPMI address is 0x20 and tries to bridge 
the sensor reading to IPMB addr 0xc2 (addr_type = IPMI_IPMB_ADDR_TYPE, 
ipmi_ipmb_addr.slave_addr=0xc2) and gets error.

Soooo, it seems I need to convince ipmitool that local address is not 
0x20 but 0xc2 using '-m' parameter and the target is 0xc2 too using 
'-t'. This seems to work, but can it be automatized? Customers don't 
like the '-m/t' voodoo, especially when ipmitool was working in the old 
version. Ipmitool could look  what's the real IPMB address instead 0x20 
at open(/dev/ipmi) time... What ioctl to use and how? I can hack the 
ipmitool part then.

Thanks in advance

Jan

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Corey M. <mi...@ac...>]

IIRC, the address in question is 0xc2, and the from below the address of 
the local card is 0xc2.  So if the SDR has the wrong address, it's not 
going to work.

And I was wrong, the driver does not detect that an IPMB message is to 
the local address and route it properly.  So ipmitool will need to know.

-corey

Jan Safranek wrote:
> On 02/04/2010 12:09 AM, Corey Minyard wrote:
>> 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
>
> hmmm, mine *already is*:
> kcs,i/o,0xca8,rsp=4,rsi=1,rsh=0,irq=0,ipmb=194
> (194 = 0xc2)
>
> I have not changed anything, just service ipmi start. I admit I don't 
> know how the kernel driver works and how it's configured - how did it 
> detect it's not 0x20? I use internal RHEL 5-like kernel and to be 
> honest, I don't know what OpenIPMI driver is there :( I might try 
> vanilla one if it helps you debug things.
>
> When getting SDR (using IPMI_SYSTEM_INTERFACE_ADDR_TYPE), SDR record 
> tells me the owner of the sensor is 0xc2 (sensor->keys.owner_id), i.e. 
> if I understand it correctly, it points to itself.
>
> But ipmitool thinks the local IPMI address is 0x20 and tries to bridge 
> the sensor reading to IPMB addr 0xc2 (addr_type = IPMI_IPMB_ADDR_TYPE, 
> ipmi_ipmb_addr.slave_addr=0xc2) and gets error.
>
> Soooo, it seems I need to convince ipmitool that local address is not 
> 0x20 but 0xc2 using '-m' parameter and the target is 0xc2 too using 
> '-t'. This seems to work, but can it be automatized? Customers don't 
> like the '-m/t' voodoo, especially when ipmitool was working in the 
> old version. Ipmitool could look  what's the real IPMB address instead 
> 0x20 at open(/dev/ipmi) time... What ioctl to use and how? I can hack 
> the ipmitool part then.
>
> Thanks in advance
>
> Jan
>

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

On 02/04/2010 03:41 PM, Corey Minyard wrote:
> IIRC, the address in question is 0xc2, and the from below the address of
> the local card is 0xc2. So if the SDR has the wrong address, it's not
> going to work.

It could work if ipmitool knows the local address. My question is, how 
to get it from /dev/ipmi? Both IPMICTL_GET_MY_ADDRESS_CMD and 
IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD (with channel 0xf) return 0x20. I 
want 0xc2... Do I really have to parse /dev/ipmi/*/params?

Jan



>
> And I was wrong, the driver does not detect that an IPMB message is to
> the local address and route it properly. So ipmitool will need to know.
> -corey
>
> Jan Safranek wrote:
>> On 02/04/2010 12:09 AM, Corey Minyard wrote:
>>> 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
>>
>> hmmm, mine *already is*:
>> kcs,i/o,0xca8,rsp=4,rsi=1,rsh=0,irq=0,ipmb=194
>> (194 = 0xc2)
>>
>> I have not changed anything, just service ipmi start. I admit I don't
>> know how the kernel driver works and how it's configured - how did it
>> detect it's not 0x20? I use internal RHEL 5-like kernel and to be
>> honest, I don't know what OpenIPMI driver is there :( I might try
>> vanilla one if it helps you debug things.
>>
>> When getting SDR (using IPMI_SYSTEM_INTERFACE_ADDR_TYPE), SDR record
>> tells me the owner of the sensor is 0xc2 (sensor->keys.owner_id), i.e.
>> if I understand it correctly, it points to itself.
>>
>> But ipmitool thinks the local IPMI address is 0x20 and tries to bridge
>> the sensor reading to IPMB addr 0xc2 (addr_type = IPMI_IPMB_ADDR_TYPE,
>> ipmi_ipmb_addr.slave_addr=0xc2) and gets error.
>>
>> Soooo, it seems I need to convince ipmitool that local address is not
>> 0x20 but 0xc2 using '-m' parameter and the target is 0xc2 too using
>> '-t'. This seems to work, but can it be automatized? Customers don't
>> like the '-m/t' voodoo, especially when ipmitool was working in the
>> old version. Ipmitool could look what's the real IPMB address instead
>> 0x20 at open(/dev/ipmi) time... What ioctl to use and how? I can hack
>> the ipmitool part then.
>>
>> Thanks in advance
>>
>> Jan
>>
>

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Corey M. <mi...@ac...>]

Jan Safranek wrote:
> On 02/04/2010 03:41 PM, Corey Minyard wrote:
>> IIRC, the address in question is 0xc2, and the from below the address of
>> the local card is 0xc2. So if the SDR has the wrong address, it's not
>> going to work.
>
> It could work if ipmitool knows the local address. My question is, how 
> to get it from /dev/ipmi? Both IPMICTL_GET_MY_ADDRESS_CMD and 
> IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD (with channel 0xf) return 0x20. I 
> want 0xc2... Do I really have to parse /dev/ipmi/*/params?
You need to use channel 0, not channel 0xf.  a slave address is 
meaningless with channel 0xf.  I just tested it and it works fine for me 
with IPMICTL_GET_MY_ADDRESS_CMD and IPMICTL_GET_MY_CHANNEL_ADDRESS with 
channel 0.

-corey

>
> Jan
>
>
>
>>
>> And I was wrong, the driver does not detect that an IPMB message is to
>> the local address and route it properly. So ipmitool will need to know.
>> -corey
>>
>> Jan Safranek wrote:
>>> On 02/04/2010 12:09 AM, Corey Minyard wrote:
>>>> 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
>>>
>>> hmmm, mine *already is*:
>>> kcs,i/o,0xca8,rsp=4,rsi=1,rsh=0,irq=0,ipmb=194
>>> (194 = 0xc2)
>>>
>>> I have not changed anything, just service ipmi start. I admit I don't
>>> know how the kernel driver works and how it's configured - how did it
>>> detect it's not 0x20? I use internal RHEL 5-like kernel and to be
>>> honest, I don't know what OpenIPMI driver is there :( I might try
>>> vanilla one if it helps you debug things.
>>>
>>> When getting SDR (using IPMI_SYSTEM_INTERFACE_ADDR_TYPE), SDR record
>>> tells me the owner of the sensor is 0xc2 (sensor->keys.owner_id), i.e.
>>> if I understand it correctly, it points to itself.
>>>
>>> But ipmitool thinks the local IPMI address is 0x20 and tries to bridge
>>> the sensor reading to IPMB addr 0xc2 (addr_type = IPMI_IPMB_ADDR_TYPE,
>>> ipmi_ipmb_addr.slave_addr=0xc2) and gets error.
>>>
>>> Soooo, it seems I need to convince ipmitool that local address is not
>>> 0x20 but 0xc2 using '-m' parameter and the target is 0xc2 too using
>>> '-t'. This seems to work, but can it be automatized? Customers don't
>>> like the '-m/t' voodoo, especially when ipmitool was working in the
>>> old version. Ipmitool could look what's the real IPMB address instead
>>> 0x20 at open(/dev/ipmi) time... What ioctl to use and how? I can hack
>>> the ipmitool part then.
>>>
>>> Thanks in advance
>>>
>>> Jan
>>>
>>
>

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

On 02/04/2010 09:06 PM, Corey Minyard wrote:
> Jan Safranek wrote:
>> On 02/04/2010 03:41 PM, Corey Minyard wrote:
>>> IIRC, the address in question is 0xc2, and the from below the address of
>>> the local card is 0xc2. So if the SDR has the wrong address, it's not
>>> going to work.
>>
>> It could work if ipmitool knows the local address. My question is, how
>> to get it from /dev/ipmi? Both IPMICTL_GET_MY_ADDRESS_CMD and
>> IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD (with channel 0xf) return 0x20. I
>> want 0xc2... Do I really have to parse /dev/ipmi/*/params?
> You need to use channel 0, not channel 0xf. a slave address is
> meaningless with channel 0xf. I just tested it and it works fine for me
> with IPMICTL_GET_MY_ADDRESS_CMD and IPMICTL_GET_MY_CHANNEL_ADDRESS with
> channel 0.

IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD with channel 0 returns 0, not 0xc2 
:(. For various channels I get the same values as in /proc/ipmi/0/ipmb:
0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

Any idea what can be wrong/how to debug it? Can it be a bug in kernel? 
Thanks in advance!

Jan

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Corey M. <mi...@ac...>]

Jan Safranek wrote:
> On 02/04/2010 09:06 PM, Corey Minyard wrote:
>> Jan Safranek wrote:
>>> On 02/04/2010 03:41 PM, Corey Minyard wrote:
>>>> IIRC, the address in question is 0xc2, and the from below the 
>>>> address of
>>>> the local card is 0xc2. So if the SDR has the wrong address, it's not
>>>> going to work.
>>>
>>> It could work if ipmitool knows the local address. My question is, how
>>> to get it from /dev/ipmi? Both IPMICTL_GET_MY_ADDRESS_CMD and
>>> IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD (with channel 0xf) return 0x20. I
>>> want 0xc2... Do I really have to parse /dev/ipmi/*/params?
>> You need to use channel 0, not channel 0xf. a slave address is
>> meaningless with channel 0xf. I just tested it and it works fine for me
>> with IPMICTL_GET_MY_ADDRESS_CMD and IPMICTL_GET_MY_CHANNEL_ADDRESS with
>> channel 0.
>
> IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD with channel 0 returns 0, not 0xc2 
> :(. For various channels I get the same values as in /proc/ipmi/0/ipmb:
> 0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
>
> Any idea what can be wrong/how to debug it? Can it be a bug in kernel? 
> Thanks in advance!
>
> Jan
>
But /dev/ipmi/0/params says 0xc2 as the address?  That is bizarre.

The slave address value from /proc/ipmi/*/params is what is passed 
directly in the ipmi_register_smi(), which is directly set as the slave 
address for channel 0.  So unless something calls the set address ioctl, 
I don't see how that could be broken.  Is it possible to boot and not 
run any IPMI programs?  Or, probably easier, the add/remove hotmod 
interface I described in an earlier email could be used to remove then 
re-add the interface.  Is it still wrong then?

Also, what kernel are you using?  Is it unmodified from k.org?

-corey

Re: [Ipmitool-devel] Broken sensors on Dell 1855 blade server

[Jan S. <jsa...@re...>]

On 02/05/2010 04:08 PM, Corey Minyard wrote:
> Jan Safranek wrote:
>> On 02/04/2010 09:06 PM, Corey Minyard wrote:
>>> Jan Safranek wrote:
>>>> On 02/04/2010 03:41 PM, Corey Minyard wrote:
>>>>> IIRC, the address in question is 0xc2, and the from below the
>>>>> address of
>>>>> the local card is 0xc2. So if the SDR has the wrong address, it's not
>>>>> going to work.
>>>>
>>>> It could work if ipmitool knows the local address. My question is, how
>>>> to get it from /dev/ipmi? Both IPMICTL_GET_MY_ADDRESS_CMD and
>>>> IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD (with channel 0xf) return 0x20. I
>>>> want 0xc2... Do I really have to parse /dev/ipmi/*/params?
>>> You need to use channel 0, not channel 0xf. a slave address is
>>> meaningless with channel 0xf. I just tested it and it works fine for me
>>> with IPMICTL_GET_MY_ADDRESS_CMD and IPMICTL_GET_MY_CHANNEL_ADDRESS with
>>> channel 0.
>>
>> IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD with channel 0 returns 0, not 0xc2
>> :(. For various channels I get the same values as in /proc/ipmi/0/ipmb:
>> 0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
>>
>> Any idea what can be wrong/how to debug it? Can it be a bug in kernel?
>> Thanks in advance!
>>
>> Jan
>>
> But /dev/ipmi/0/params says 0xc2 as the address? That is bizarre.
>
> The slave address value from /proc/ipmi/*/params is what is passed
> directly in the ipmi_register_smi(), which is directly set as the slave
> address for channel 0. So unless something calls the set address ioctl,
> I don't see how that could be broken. Is it possible to boot and not run
> any IPMI programs? Or, probably easier, the add/remove hotmod interface
> I described in an earlier email could be used to remove then re-add the
> interface. Is it still wrong then?
>
> Also, what kernel are you using? Is it unmodified from k.org?

No, as I wrote, it's RHEL 5.4 - 2.6.18 + lot of patches. Today I've 
tested Fedora 12 flavor of 2.6.31.5 and I get correct data with 
IPMICTL_GET_MY_ADDRESS_CMD. That means there must something wrong in 
RHEL kernel... I'll pass it to appropriate guys.

Thanks a lot for your help!

Jan