Menu
▾
▴
1 Attachments
#416 The bridge command will failed to get sensor and fru information
Our server communicates with the storage via IPMB, so we try to use bridge command to do some action such as ipmitool sensor, ipmitool sdr, ipmitool fru. We found that these commands will get incorrect value because the bridge target address(storage's address) has been changed to the server address.
The code of the above statment are show as below:
if ( BRIDGE_TO_SENSOR(intf, target, channel) ) {
bridged_request = 1;
save_addr = intf->target_addr;
intf->target_addr = target;
save_channel = intf->target_channel;
intf->target_channel = channel;
}
I believe this patch is going to break all other platforms which are bridged and rely on the current implementation. Why is this change necessary?
Hi,
We must to send the bridge command from server to storage and the goal is to get the sensor reading which the sensors are in the storage not in the server. Base on the current implementation the target address of this bridge command will be changed, so that the request can not be sent to the correct address. The incorrect sensor value is induced by the above reason.
I think, if anybody want to excute the bridge command in one server to get the sensor reading from another platform will have the same problem.
If there is any misunderstanding, please feel free to let me know.
Thank you for your discussion and also appreciative of your help.
I think there is something wrong with the way in which your platform is identifying where the sensor actually resides when it reports the sensor via the SDR repository. If the sensor resides in storage, then I believe that your SDR repository should identify the storage address and channel of the sensor, not the server address and channel of the sensor. It sounds to me like your SDR repository is identifying the sensor as residing on your server, not in storage.
The current code uses the sensor target address and channel as identified in the SDR repository when bridging is used. Your code changes ignore the address and channel that are specified for the sensor in the SDR repository and assume that they are at the identified interface target address and channel.
What exactly is your platform reporting in the SDR repository as the owner id and channel for the sensor? What is the platform you are using?
Hi,
Let me give you an example in our platform and explain this issue again.
Our server communicates with the storage via IPMB.
The storage address is 0x22 and channel is 0x06.
The storage's mc info:
[root@localhost src]# ipmitool -UUSERID -PPASSW0RD -H1111::299 -t 0x22 -b 0x06 mc info
Device ID : 32
Device Revision : 1
Firmware Revision : 1.02
IPMI Version : 2.0
The server's mc info:
[root@localhost src]# ipmitool -UUSERID -PPASSW0RD -H1111::299 mc info
Device ID : 32
Device Revision : 1
Firmware Revision : 7.04
IPMI Version : 2.0
First, I log into the storage and excute: ipmitool -UUSERID -PPASSW0RD -H127.0.0.1 sdr
The result are show as below.
PDPB Volt 3V3 | no reading | ns
PDPB Volt 2V5 | no reading | ns
PDPB Volt 12VSSD | no reading | ns
PDPB Volt 12V | no reading | ns
PDPB Temp 1 | no reading | ns
PDPB Temp 2 | no reading | ns
PDPB Temp 3 | no reading | ns
PDPB Temp 4 | no reading | ns
BJT Temp Sensor1 | no reading | ns
BJT Temp Sensor2 | no reading | ns
FCB Volt 12.5V_1 | no reading | ns
FCB Volt 12.5V_2 | no reading | ns
FCB Volt 12.5V_3 | no reading | ns
FCB Volt 3.3V | no reading | ns
FCB Voltage | no reading | ns
FCB Current | no reading | ns
FCB Power | no reading | ns
Fan 1 Front | no reading | ns
Fan 1 Rear | no reading | ns
Fan 2 Front | no reading | ns
Fan 2 Rear | no reading | ns
Fan 3 Front | no reading | ns
Fan 3 Rear | no reading | ns
Fan 4 Front | no reading | ns
Fan 4 Rear | no reading | ns
Fan 5 Front | no reading | ns
Fan 5 Rear | no reading | ns
Fan 6 Front | no reading | ns
Fan 6 Rear | no reading | ns
PEB Volt12Main | 12.22 Volts | ok
PEB Volt 5V_STBY | 4.70 Volts | ok
PEB Volt 3.3V | 3.20 Volts | ok
PEB Volt 1.8V | 1.71 Volts | ok
PEB Volt 1.53V | 1.42 Volts | ok
PEB Volt 0.9V | 0.91 Volts | ok
PEB Volt 0.9V_E | 0.83 Volts | ok
PEB Volt 1.26V | 1.43 Volts | ok
PEB Voltage 12V | no reading | ns
PEB Current | no reading | ns
PEB Watt | no reading | ns
PCIe SW Temp. | no reading | ns
PCIe SW Am Temp. | no reading | ns
Ambient Temp. 1 | no reading | ns
Ambient Temp. 2 | no reading | ns
SEL_sensor | 0x00 | ok
Watchdog2 | 0x00 | ok
The above result is the correct answer.
Then, I log into the server. The goal is to get the storage's sdr.
The server communicates with the storage via IPMB.
The storage address is 0x22 and channel is 0x06.
I expected that the result of ipmitool -UUSERID -PPASSW0RD -H1111::299 -t 0x22 -b 0x06 sdr will be the same as the above.
But I get the inccorect result as below.
PDPB Volt 3V3 | no reading | ns
PDPB Volt 2V5 | no reading | ns
PDPB Volt 12VSSD | no reading | ns
PDPB Volt 12V | no reading | ns
PDPB Temp 1 | no reading | ns
PDPB Temp 2 | no reading | ns
PDPB Temp 3 | disabled | ns
PDPB Temp 4 | disabled | ns
BJT Temp Sensor1 | no reading | ns
BJT Temp Sensor2 | no reading | ns
FCB Volt 12.5V_1 | 7.32 Volts | ok
FCB Volt 12.5V_2 | 0.06 Volts | ok
FCB Volt 12.5V_3 | 0 Volts | ok
FCB Volt 3.3V | 2.44 Volts | ok
FCB Voltage | 0 Volts | ok
FCB Current | 0 Amps | ok
FCB Power | 488 Watts | ok
Fan 1 Front | 0 RPM | ok
Fan 1 Rear | 56 RPM | ok
Fan 2 Front | disabled | ns
Fan 2 Rear | disabled | ns
Fan 3 Front | disabled | ns
Fan 3 Rear | disabled | ns
Fan 4 Front | disabled | ns
Fan 4 Rear | disabled | ns
Fan 5 Front | disabled | ns
Fan 5 Rear | no reading | ns
Fan 6 Front | no reading | ns
Fan 6 Rear | no reading | ns
PEB Volt12Main | no reading | ns
PEB Volt 5V_STBY | disabled | ns
PEB Volt 3.3V | no reading | ns
PEB Volt 1.8V | no reading | ns
PEB Volt 1.53V | 0.16 Volts | ok
PEB Volt 0.9V | 0.16 Volts | ok
PEB Volt 0.9V_E | no reading | ns
PEB Volt 1.26V | no reading | ns
PEB Voltage 12V | no reading | ns
PEB Current | 0.51 Amps | ok
PEB Watt | no reading | ns
PCIe SW Temp. | disabled | ns
PCIe SW Am Temp. | no reading | ns
Ambient Temp. 1 | no reading | ns
Ambient Temp. 2 | disabled | ns
SEL_sensor | 0x1b | ok
Watchdog2 | 0x1d | ok
After that, I check with the -vvvvv option.
I found this message "Bridge to Sensor Intf my/0x20 tgt/0x22:0x6 Sdr tgt/0x20:0".
This means the target address 0x22 has been changed to 0x20.
I also trace the source code and find that the target address and channel will be changed when we try to bridge to sensor.
The code are show as below.
if ( BRIDGE_TO_SENSOR(intf, target, channel) ) {
bridged_request = 1;
save_addr = intf->target_addr;
intf->target_addr = target;
save_channel = intf->target_channel;
intf->target_channel = channel;
}
Thus I remove these two lines:
intf->target_addr = target; //This line cause the intf->target_addr(0x22) changes into 0x20.
intf->target_channel = channel;
After that, I try to excute "ipmitool -UUSERID -PPASSW0RD -H1111::299 -t 0x22 -b 0x06 sdr" again.
The results are correct as below.
[root@localhost src]# ./ipmitool -UUSERID -PPASSW0RD -H1111::299 -t 0x22 -b 0x06 sdr
PDPB Volt 3V3 | no reading | ns
PDPB Volt 2V5 | no reading | ns
PDPB Volt 12VSSD | no reading | ns
PDPB Volt 12V | no reading | ns
PDPB Temp 1 | no reading | ns
PDPB Temp 2 | no reading | ns
PDPB Temp 3 | no reading | ns
PDPB Temp 4 | no reading | ns
BJT Temp Sensor1 | no reading | ns
BJT Temp Sensor2 | no reading | ns
FCB Volt 12.5V_1 | no reading | ns
FCB Volt 12.5V_2 | no reading | ns
FCB Volt 12.5V_3 | no reading | ns
FCB Volt 3.3V | no reading | ns
FCB Voltage | no reading | ns
FCB Current | no reading | ns
FCB Power | no reading | ns
Fan 1 Front | no reading | ns
Fan 1 Rear | no reading | ns
Fan 2 Front | no reading | ns
Fan 2 Rear | no reading | ns
Fan 3 Front | no reading | ns
Fan 3 Rear | no reading | ns
Fan 4 Front | no reading | ns
Fan 4 Rear | no reading | ns
Fan 5 Front | no reading | ns
Fan 5 Rear | no reading | ns
Fan 6 Front | no reading | ns
Fan 6 Rear | no reading | ns
PEB Volt12Main | 12.22 Volts | ok
PEB Volt 5V_STBY | 4.70 Volts | ok
PEB Volt 3.3V | 3.20 Volts | ok
PEB Volt 1.8V | 1.71 Volts | ok
PEB Volt 1.53V | 1.42 Volts | ok
PEB Volt 0.9V | 0.91 Volts | ok
PEB Volt 0.9V_E | 0.83 Volts | ok
PEB Volt 1.26V | 1.43 Volts | ok
PEB Voltage 12V | no reading | ns
PEB Current | no reading | ns
PEB Watt | no reading | ns
PCIe SW Temp. | no reading | ns
PCIe SW Am Temp. | no reading | ns
Ambient Temp. 1 | no reading | ns
Ambient Temp. 2 | no reading | ns
SEL_sensor | 0x00 | ok
Watchdog2 | 0x00 | ok
That's the problem I met.
Why is it necessary to change the target address when it is a bridge command to sensor?
BTW, the command "ipmitool mc info" doesn't have this problem.
Feel free to let me know, if I don't explain it clearly.
Thank you.
Last edit: Bonnie_Lo 2016-02-11
This issue is that the SDR repository entry you read from your server for the sensor is Sdr tgt/0x20:0, not what you want it to be Sdr tgt/0x22:0x6. With bridging, the target address of the sensor comes from the SDR repository, not from your bridge command line arguments.
I believe the code is correct as written and will work when the SDR repository contains the correct addresses of the sensors. When I get some more time I will go back and look more carefully at the code to make sure what is printed below is 100% correct with regard to my explaination, but you could do this as well.
The message you show below indicates what I attempted to explain above:
After that, I check with the -vvvvv option.
I found this message "Bridge to Sensor Intf my/0x20 tgt/0x22:0x6 Sdr tgt/0x20:0".
This means the target address 0x22 has been changed to 0x20. I would change your to tex to read: This means that target address of the sensor has been changed to what the SDR reports as the address of the sensor 0x20:0
Hi,
Sorry for my late response.
I think you mistook my meaning.
The attachment is the picture to show the platform we use.
What I want to do is to log into host A and excute the command:
ipmitool -t 0x22 -b 0x06 sdr
The SDR where I want to read is from SDR repository B not from SDR repository A.
If ipmitool change the target address from 0x22 to 0x20, then I will get the SDR from SDR repository A not what I want the SDR in SDR repository B.
If you check the code, you will found that only use bridge command to FRU, SDR and SENSOR will meet this problem.
if ( BRIDGE_TO_SENSOR(intf, target, channel) ) {
bridged_request = 1;
save_addr = intf->target_addr;
intf->target_addr = target;
save_channel = intf->target_channel;
intf->target_channel = channel;
}
Could you please tell me why ipmitool need to use this if statment to change the slave address for the bridge command to sensor at that moment.
I think it's the key problem.
I really wonder why the slave address cannot be the address of slave device instead of address of my device.
Also very thank you for your help.
If there are any new discoveries, please let me know.
Last edit: Bonnie_Lo 2016-02-16
Hi,
I believe I understand what you want and that the code could be changed based on your need. The problem is that doing what you want will cause other platform bridged implementations that are currently working to fail. At this point, I think you should take a look at the IPMI specification with regard to how IPMI bridging works. The current implementation in ipmtool was done based on what is in the IPMI specification and discussions with folk on the ipmitool developers alias. If you can point out where the current code is incorrectly implementing bridging per the IPMI specification, then a conversation on the ipmitool developer email thread pertaining to the change would probably be the best way to move forward with a change.
Here is some information I derived from the ipmitool code a while back as to how ipmitool bridging arguments are used that might be useful. It could be you simply need to change how you are using ipmitool to accomplish what you want.
There are two different bridging argument specifications, -t target_address/-b target_channel (single bridge), and -T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read the SDR repository
if the address specified by -t is not equivalent to the ipmitool identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of 0x20, or specified
on the command line via the -m address switch, or discovered via PICMG get address
info.
In addition to -t, you may also specify a transit address via -T. If a transit address is
specified, dual bridging will be used to read the SDR repository (via the transit address
to get to the target identified via -t). The specification of a transit address without a
target address is meaningless as the transit address is not used unless there is a target
address specification with -t.
Now, in addition to bridging to read the SDR repository, bridging will also occur to access
an individual sensor if the sensor owner id identified in the SDR repository does not match
the ipmitool identified IPMB-0 address. This bridging will override the specified target address
identified via the -t switch, but will make use of the transit address (and dual bridge) when
both -t and -T are specified.
Last edit: Jim Mankovich 2016-02-16
Hi,
Thank you for your explaination about the single/dual bridge command.
Let me ask one more question.
From my understanding, I think the bridge command will get the same sensor reading value for the same sensor number whenever I use the raw command or the string command such as "sensor get <sensor ID="">".
But the following result is not in my expectation:
I excute the raw command to "get sensor reading".
[root@localhost]# ipmitool -t 0x22 -b 0x06 raw 0x4 0x2d 0x51
00 e0 00 80
The "e0" means "No Reading" and that is the correct answer.
Then, I excute the command "sensor get "PDPB Temp 3"".
This command also can get the sensor value of the sensor number which is 0x51.
The result show as below. You can find the Sensor Reading is "Disable" not "No Reading"
[root@localhost]# ipmitool -t 0x22 -b 0x06 sensor get "PDPB Temp 3"
Locating sensor record...
Sensor ID : PDPB Temp 3 (0x51)
Entity ID : 15.0 (Drive Backplane)
Sensor Type (Threshold) : Temperature (0x01)
Sensor Reading : Disabled
...
Why these two command will get the different result?
Is that measure up to your expectation?
I am looking forward to your reply.
You stated No Reading as being the correct interpretation for "e0", but each individual bit has a specific interpretation per the IPMI specification. 'No Reading' is certainly set, as is 'Scanning Disabled', and also, 'All Event Messages disabled from this senso'r. So, "Disabled" is also correct. One can assume "No Reading" for a "Disabled" sensor, but I don't think the converse can be assumed.
If you look at the IPMI specification, page 452 for details pertaining to the interpretation of "e0" you will see that each bit has a specific meaning. As currently implemented, ipmitool attempts to follow the IPMI specification with regard to individual bit decoding.
Hi,
As you said, I think I need to change my usage of ipmitool to accomplish what I want.
I take some time to check your advice about the dual bridge command.
First, I need to let you know that It dosn't support PICMG in my platform.
I try to use the -T transit_address/-B transit_channel option to specify the transit address.
The help show me:
-m address Set local IPMB address
-b channel Set destination channel for bridged request
-t address Bridge request to remote target address
-B channel Set transit channel for bridged request (dual bridge)
-T address Set transit address for bridge request (dual bridge)
As I know, the entire command should be "ipmitool -UUSERID -PPASSW0RD -H1111::2ad -T 0x20 -B 0x0 -t 0x22 -b 0x6 sdr"
In the picture of our platform:
the target address of IPMC B : 0x22/0x06
the SDR repository address of IPMC B: 0x20/0x00
The result of the above command also get the incorrect value. It also get the information from SDR repository A not from repository B.
Maybe I need more time to trace the code to check the reson why it dosen't work.
I still want to check with you, if you think that I lost the important information about the usage of dual bridge command.
Is that still my wrong usage of ipmitool?
Best Regards,
Bonnie
Bonnie,
You might try using only dual bridge and setting a local IPMB address with -m switch. (-m, -B, -T) only.
Hi,
I think I can't only use the dual bridge, cause the ipmitool will show me that target address must be specified.
[root@localhost src]# ./ipmitool -V
ipmitool version 1.8.15
[root@localhost src]# ./ipmitool -T 0x22 -B0x06 -m 0x20 sdr
Transit address/channel 0x22/0x6 ignored. Target address must be specified!
[root@localhost src]# ./ipmitool -T 0x20 -B 0x00 -m 0x22 sdr
Transit address/channel 0x20/0 ignored. Target address must be specified!
[root@localhost src]# ./ipmitool -T 0x20 -B 0x00 -m 0x20 sdr
Transit address/channel 0x20/0 ignored. Target address must be specified!
It's not normal, right?
I don't know what wrong with it.
Bonnie,
What I mentioned to do was simply a suggestion, so if ipmitool tells you you need all the arguments, than that is the correct thing to do. Turn on debug output with ipmitool and try using -m in addition to other aguments and see how -m and the arguments effect what gets read by ipmitool.
The following text really doesn't make any sense me with regard to the picture as you say IPMC B: has two different addresses??
"In the picture of our platform:
the target address of IPMC B : 0x22/0x06
the SDR repository address of IPMC B: 0x20/0x00"
You stated that "ipmitool -UUSERID -PPASSW0RD -H1111::2ad -T 0x20 -B 0x0 -t 0x22 -b 0x6 sdr", gets you the information from SDR repository A not from repository B.
Have you tried reversing the bridging arguments?
"ipmitool -UUSERID -PPASSW0RD -H1111::2ad -T 0x22-B 0x6 -t 0x20 -b 0x0 sdr"
You could also try specifying the IPMB-0 address to use as -m 0x22 as another possibility.
Last edit: Jim Mankovich 2016-02-23
Hi Jim,
Thank you for your advice.
I want to share one thing I found with you.
I trace the code and compare the code flow of bridge command between raw command and string command.
The raw command is like "ipmitool -t 0x22 -b 0x06 raw 0x4 0x2d 0x51"
The string command is like "ipmitool -t 0x22 -b 0x06 sensor get "PDPB Temp 3""
PS. The sensor number 0x51 named "PDPB Temp 3".
These two commands have the same goal to do sensor reading.
I understand the string command also help the user to decode the raw data.
I think they all need to send the sensor reading command (NETFN: 0x4, CMD: 0x2d)from ipmitool to BMC.
Let me show you the code flow about the raw command:
ipmitool.c:main()->ipmi_main.c:ipmi_main()->ipmi_raw.c:ipmi_raw_main()
In function ipmi_raw_main(), you will call intf->sendrecv(intf, &req) to get the respons.
I print the target address in this moment, the target address is 0x22 and request netfn is 0x4 the command code is 0x2d.
The code flow about the string command:
ipmitool.c:main()->ipmi_main.c:ipmi_main()->ipmi_sensor.c:ipmi_sensor_main()->.....->ipmi_sdr_get_sensor_reading_ipmb()
I skip some steps in my flow.
The important things I want to show you is In function ipmi_sdr_get_sensor_reading_ipmb().
Here the target address will be changed from 0x22 to 0x20 and the request netfn is 0x4 the command code is 0x2d.
The following code will change the target address.
if ( BRIDGE_TO_SENSOR(intf, target, channel) ) {
lprintf(LOG_DEBUG,
"Bridge to Sensor "
"Intf my/%#x tgt/%#x:%#x Sdr tgt/%#x:%#x\n",
intf->my_addr, intf->target_addr, intf->target_channel,
target, channel);
bridged_request = 1;
save_addr = intf->target_addr;
intf->target_addr = target;
save_channel = intf->target_channel;
intf->target_channel = channel;
}
I want to read the same sensor but one is using the raw command and the other is using the string command. Why the sensor reading command(NETFN: 0x4, CMD: 0x2d) will be sent to the different target address?
I feel confused. could you please give me some explaination?
Please let me know, if you don't understand my the confusion.
The raw command will not look up the sensor in the SDR, it simply uses your -t specified target as the address of the sensor.
The sensor get command reads the SDR using your -t specified target address and then looks up the sensor in the SDR (usng the name you specified), to get the sensor address. It then uses the address of the sensor it found in the SDR to read the sensor.
Hi Jim,
Thank you for your answer. It's very clearly and helpful.
I still want to realize the dual bridge command, so I trace the code for the option -T and -B.
If I use the -T option , the source code in open.c will modify target address to use 'transit address'.
ipmb_addr.slave_addr = intf->transit_addr;
ipmb_addr.channel = intf->transit_channel;
Then, fill the data as below:
data[index++] = (0x40|intf->target_channel);
data[index++] = intf->target_addr;
data[index++] = ( req->msg.netfn << 2 ) | req->msg.lun ;
data[index++] = ipmi_csum(data+1, 2);
data[index++] = 0xFF; / normally 0x20 , overwritten by IPMC /
data[index++] = ( (0) << 2) | 0 ; / FIXME /
data[index++] = req->msg.cmd;
memcpy( (data+index) , req->msg.data, req->msg.data_len);
index += req->msg.data_len;
data[index++] = ipmi_csum( (data+4),(req->msg.data_len + 3) );
I have a question.
If I only use -t/-b options, ipmitool won't do the above code.
Why the -T/-B option need to convert the data at that moment by using the above code?
I don't really understand the different between single bridge command(-t/-b) and dual bridge command(-T/-B).
Could you please give me more expaination about the code?
It'll be great if you can give me an example or an use case for which platform or which situation the user need to use the dual bridge command (-T/-B option)?
Bonnie,
I don' t have any examples.
For an explanition of what the code above implements, (Dual vrs Single level bridging) you have to look at tthe IPMI spec. I believe there is an encapsulation of additional address information in an IPMI package for dual briding (one address used to transmit to the target and another in the packet for use in addressing at the target), but not an extra encapsulation for single bridging.
There is certainly a problem associated with IPMI based bridging between your server and storage or in the way ipmitool works with regard to bridging on your platform, but I can't help since I don't know how the bridging on your platforms is implemented. If we knew how the bridging was implemented, we could figure out what the problem is.
We need more info on how your platform are implemented with regard to IPMI bridging.
The problem you are seeing is due to how each of your platforms SDR repositories identify sensor addressing. With bridging, ipmitool will read the SDR repository at your specified target and then use the sensor addressing information in the SDR, at the target, to address the sensor. This doesn't work on your platform because the Sensor addresses in the SDR repositories on both of your platforms identify sensor addresses with a local IPMB-0 address of 0x20.
Your platforms SDR repository implementation is also why the change you made to ipmitool works. Your change ignores the address of the SDR in the repository at the target and overrides it with what you specified on the command line.
If the SDR repository on your platform B (at address 0x22) identified the addresses of the Sensors in the SDR repository as having address 0x22 (which they really should have since the Sensors reside on Host B at address 0x22) then single level bridging will work for you (You proved this with your change to ipmitool).
Right now, both Host A and Host B have SDR repositories which identify SDR addresses as having address 0x20 so they really can't be bridged.
Hello,
please, what's the status of this ticket? Can it be closed?
Thanks,
Z.
Thank you very much.
This issue can be closed.
Thank you for letting me know Bonnie.
Z.