Hi Ralf,
no I haven’t. I’m still new to ipmi world.
Cheers,
Rongkun
Hi Guys,
I am the developer of the MMC firmware implemented on the mezzanine card. I can fill in some blanks in case it helps.
We don’t have all the compatible parts to test a double bridge sdr fill request with a diferent setup, but we did some in depth tests with this one and it doesn’t llok like the problem is on the MMC or ipmitool. The logs appear to show the issue is caused by some kind of timeout on the ipmc side.
Maybe some of the details of our tests can lead you into the rigth direction, or maybe there is something we have not interpreted correctly.
While we were successful applying the sdr file using a bridge command:
ipmitool -H 192.168.0.200 -P “” -t 0x72 -b 7 sdr fill file mezz_thermal_1_revc_3.sdr
We failed when we tried to use a double bridge request over the shcm:
ipmitool -H 192.168.88.251 -P “” -T 0x8C -t 0x72 -B 0 -b 7 sdr fill file mezz_thermal_1_revc_3.sdr
The output of ipmitool for the double bridge commands shows that the partial add requests fail:
...
ipmitool: partial add failed
Cannot add SDR ID 0x0001 to repository...
ipmitool: partial add failed
Cannot add SDR ID 0x0002 to repository...
ipmitool: partial add failed
...
By monitoring the IPMI traffic on the MMC side we have noticed that only the first bytes of each sdr are sent by the IPMC to the MMC:
Reserve SDR Repository:
R-10-1-72 28 66 20 A8 22 16
T- 0-1-20 2C B4 72 A8 22 00 97 00 2D
Partial ADD SDR
R-11-1-72 28 66 20 AC 25 97 00 00 00 00 00 02 00 51 01 3A EA
T- 0-1-20 2C B4 72 AC 25 00 00 00 BD
Get Sensor Reading:
R-12-1-72 10 7E 20 B8 2D 78 83
T- 0-1-20 14 CC 72 B8 2D **CB** DE
Get Sensor Reading:
R-13-1-72 10 7E 20 BC 2D 78 7F
T- 0-1-20 14 CC 72 BC 2D **CB** DA
I have noticed two things in the log:
-
The MMC acknowledges the first bytes, but the IPMC never forwards the following bridge messages it gets from ipmitool via the shmc containing the rest of the SDR. On the other side of the link, probably the ipmitool times-out and moves on to the next sdr. The story repeats itself over and over with the MMC receiving only a Reserve SDR Repository request and the first 5 bytes of each SDR until the file is completely read.
-
Besides the commands it has to forward from ipmitool, the IPMC continues to poll the sensors of the MMC. That is probably the reason for the Get Sensor Reading requests that appear in the log. As the sdrs of the MMC were erased as part of the sdr update process, there is nothing to be polled until the update is finished. This is why all the Get Sensor Reading requests will receive a response of 0xCB → Sensor Not Present until the sdr file is received completely. Maybe this completion code triggers a unexpected behavior on the IPMC thus blocking the folowing ipmi mesages that was suposed to be forwarded from ipmitool.
In case of updating the sdr using a single bridge command and having ipmitool communicate directly to the IPMC instead of routing through the ShMC as a double bridge, the process is a lot faster and all the required IPMI requests fit between the sensor polling requests. In this case there are no Get Sensor Reading requests that get the 0xCB completion code between the requests of the sdr update process. Maybe this is the reason the process is successful for bridge commands and not for double bridge, or maybe it is just a coincidence.
Sorry for the long post, but I tried to give some context to the failure.
Regards,
Andrei
Hi Andrei,
Thanks for your detailed report. We have sent your message to PigeonPoint Systems to get their feedback, and ti seems there is some misunderstanding, which I will follow up with them. But they are suggesting to enable the debugging on the IPMC - do you have an Serial Debug Interface connected to the IPMC? If so, you could run the following commands to it:
The following SDI command enables message dump for all channels:
[b8 00 04 0a 40 00 FF]And this command reverts to default verbosity:
[b8 00 04 0a 40 00 07]
If you then could run the double-bridge sequence once more, what do you see?
Cheers,
Ralf.