Another thing, I also saw some checksum change with the ipmiutil-3.1.9.tar.gz - sha256 "c0dacc4ad506538f59ed45373b775748deddddc36e6d3c303f5069a59cacab08" + sha256 "5ae99bdd1296a8e25cea839784ec39ebca57b0e3701b2d440b8e02e22dc4bc95" was there some aritfact re-uploading for 3.1.9 release? Thanks!
Thanks for the patch, it actually should be typedef struct { int val; char *str; } vFlashstr; rather than typedef struct { int value; char *string; } vFlashstr; Other than that, it works well for me, thanks! gonna ship with https://github.com/Homebrew/homebrew-core/pull/191136
failed to build 3.1.9 for macos sequoia
It looks like this particuar compiler does not handle these 'const struct vFlashstr' declarations properly. It must need the struct defined explicitly. There are several other oem*.c files affected if so. const struct vFlashstr vFlash_completion_code_vals[] = {... }; I have attached an updated ocm_dell.c which should work better. Please try with that and let me know if it gets past ocm_dell.c now.
failed to build 3.1.9 for macos sequoia
getevt exits with return code ( rv = -3)
Request for Guidance on Testing IPMIutil with a Simulated BMC Server
Request for Guidance on Testing IPMIutil with a Simulated BMC Server
ipmiutil alarm/health not working on Windows
I appreciate your time and your response.
Let's review the questions you posed: 1) Is there a method to test ipmiutil without a physical IPMI server? A: The purpose of ipmiutil is to support physical IPMI servers, but it may work with the simulators for functions that do not require two-byte sensors (outside the IPMI standard). 2) What is the 'driverless' option in ipmiutil? Normally, when configuring IPMI on a server, it is run locally, and a driver is required for the OS to talk to the IPMI firmware. Key drivers: openipmi (Linux), imb...
Let's review the questions you posed: 1) Is there a method to test ipmiutil without a physical IPMI server? A: The purpose of ipmiutil is to support physical IPMI servers, but it may work with the simulators for functions that do not require two-byte sensors (outside the IPMI standard). 2) What is the 'driverless' option in ipmiutil? Normally, when configuring IPMI on a server, it is run locally, and a driver is required for the OS to talk to the IPMI firmware. Key drivers: openipmi (Linux), imb...
May I kindly request an explanation on this, please?
I am attempting to test ipmiutil using the ipmi_if.txt file and have encountered the following result: # cat ipmi_if.txt # IPMI Device Information device /tmp/.ipmi_dummy # # ipmiutil sel -v -f ipmi_if.txt ipmiutil sel version 3.19 RecId Date/Time_______ SEV Src_ Evt_Type___ Sens# Evt_detail - Trig [Evt_data] 2cde Type0f INF 69 e2 62 de 62 0a 00 00 00 00 01 78 3a ipmiutil sel, completed successfully # I'm interested in understanding the meaning of the output, specifically the line 2cde Type0f INF...
What is the 'driverless' option in ipmiutil? Could you explain it to me?
There are some ipmiutil commands that do not require sensor ids which should work with the simulators (like health, reset, wdt), but if the command to the simulator requires two bytes for sensors, it currently won't work with ipmiutil. It would be a large effort to add support for two-byte sensor ids throughout the code. The purpose of IPMI is to manage physical servers with IPMI firmware.
May I kindly request an update on this, please?
Thank you for your response. Is there a method to test ipmiutil without a physical IPMI server?
I'm not familiar with IPMISIM, but I know that Corey Minyard wrote ipmi_sim, and he has been a key developer in IPMI for a long time. I don't know much about the IPMI simulators, except that some of them have gone beyond the IPMI spec (expanded the number of sensors beyond one byte). I deal mostly with IPMI firmware.
Request for Guidance on Testing IPMIutil with a Simulated BMC Server
FYI, you can see the actual version of ipmiutil.exe each time you run it (3.1.9 will show as 3.19).
Apparently with the 3.1.9 MSI, I must have not updated that instance of the version number from 3.1.8 to 3.1.9. Sorry for the confusion.
I noticed after running the 3.1.9 .MSI installer on windows, under add/remove programs (appwiz.cpl), it shows 3.1.8 is "installed". Not sure if this is a type-o or 3.1.8 was accidentally packaged as 3.1.9?
It could be an issue with specifying the field, or a restriction built into the firmware. If you could send the ifru debug output for this command adding -x, we should be able to find the cause. Andy On Sat, May 20, 2023 at 1:34 AM u-sanada bengal00@users.sourceforge.net wrote: I would like to change the serial number of the Fujitsu PRIMERGY RX2530M1, but it is not possible. ifru -s <serial number=""> command is input, but writing ends with an error. This Server synchronizes information between the...
I would like to change the serial number of the Fujitsu PRIMERGY RX2530M1, but it is not possible. ifru -s <serial number=""> command is input, but writing ends with an error. This Server synchronizes information between the motherboard and the front panel, which we call the chassis, and I think this has something to do with it. If there is a way to use ipmiutil or ifru or another way to write serial numbers to chassis and motherboard respectively It would be helpful if you could tell me. Thank ...
Is it helpful for "InstantEvents" so i can manage the staff and other crew members.
That is not a topic that is related to this software. Ipmiutil is an opensource software project to enable managing physical servers that support IPMI firmware.
Is it helpful for Instant Events so i can manage the staff and other crew members.
ipmiutil_wdt.service did not start
A fix for this is included in ipmiutil-3.1.9 (renaming $prog to $progn) at https://ipmiutil.sf.net
SMBIOS entry point
A fix for this is now published in ipmiutil-3.1.9 at http://ipmiutil.sf.net In order for it to be handled in Linux, Windows, BSD, etc., I used the literal 0x6d5a7000 instead of getting it from systab.
Issues with windows msi installer
The fix for this is now published in ipmiutil-3.1.9 at http://ipmiutil.sf.net
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
The fix for this is now published in the ipmiutil-3.1.9 release at http://ipmiutil.sf.net.
Hi Andy, Sorry for the delayed response. When i compile and load this on my device, I am getting some issues regarding shared libraries, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine. I see that you have made it obselete in the code. so it must work.
Hi Andy, Sorry for the delayed response. I am getting some issues regarding shared libraries, when i compile and load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine. I see that you have made it obselete in the code. so it must work.
Hi Andy, Sorry for the delayed response. I am getting some issues with respect libraries, when i compile and load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine. I see that you have made it obselete in the code. so it must work.
Hi Andy, Sorry for the delayed response. I am getting some issues with respect libraries, when i compile and load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine.
Hi Andy, Sorry for the delayed response. I am getting some issues with respect libraries, when i load this on my device, but I have tested removing the is_romley check in 3.1.5 and shutdown is working fine.
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
OK. I have been preparing a new ipmiutil-3.1.9 release, and I have added this change to ireset.c in it. Can you try it and verify that it resolves this problem? https://ipmiutil.sourceforge.net/FILES/ipmiutil-3.1.9.tar.gz I provided the source tarball, since I don't know which OS flavor you are running.
Yes, it works without that check.
Good question. Originally the Romley systems had different soft shutdown support. The Intel Romley servers were from around 2010 IIRC, so it is possible Intel has reused the Romley ID for a different model, but they've never done that before. In any case, we need to remove the is_romley check in ireset.c based on your experience. If you do that on your system, it works, right?
Hi Andy, How significant is is_romley() check in ireset.c? I see that problem can be resolved by removing this check.
Changing from ipmi_cmd to ipmi_cmd_mc is what allows this to run either normally or via IPMB. For the command that repeats, It is a Chassis Control soft-shutdown command. ipmidir Cmd=02 NetFn=00 Lun=00 Sa=20 Data(1): 05 Send Netfn=00 Cmd=02, raw: 00 20 00 02 05 ipmidir Resp(1,2): status=0 cc=cf, Data(0): 28.3 Chassis Control Command (0x02) 0h = power down 1h = power up 2h = power cycle 3h = hard reset 4h = pulse Diagnostic interrupt 5h = soft-shutdown of OS via ACPI The fact that this returns completion...
Hi Andy, After the upgrade , we moved from drivermode to driverless mode. so it was expected that open ipmi driver not being there. I tried to fallback to driver mode by creating /dev/ipmi0 . but i got the same output even after doing so. The issue seems to have originated from platform type. As platform was not platIntel, it missed to set watchdog and moved to chassis_ctl command and the corresponding output is seen in 3.1.5 log. Is there any reason you could think of, why the particular command...
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
It looks like there is a different in the driver type (openipmi vs. direct): In the 2.79 debug it opens the MV openipmi driver ok: ~~~ipmi_open: driver type = unknown ipmi_open_mv: cannot open /dev/ipmi/0 ipmi_open_mv: succesfully opened /dev/ipmi0, fd=4 ipmi_open rc = 0 type = open Driver type open, open rc = 0 But in the 3.15 debug, it fails to open MV openipmi and falls back to directio. ipmi_open: driver type = ipmi_open_mv: cannot open /dev/ipmi/0 ipmi_open_mv: cannot open /dev/ipmi0 ipmi_open_mv:...
and this change (((bpower >= 5) && (platform == platIntel)) is restricting watchdog to run as part of ipmi_reset()
From deeper inspection, the following function is_romley(vendid,prodid) is returning true, and giving the same hardware a different platform for the same hardware in 3.1.5
"ipmiutil reset -D" doesn't soft shutdown specific hardware.
ipmi_cmd (GET_SEL_ENTRY) returns response with incorrect id.
Sorry for the delay. I just realized that I didn't respond to your latest ipmiutil_evt.log. It includes records from 0122 through 03f5 but doesn't show the 0dff records or beyond (before the SEL was cleared). It looks like we don't have enough evidence to find out what went wrong in this instance. My best guess is that one of the earlier records had a malformed event that caused it to point to 2200.
Sorry for the delay. I just realized that I didn't respond to your latest ipmiutil_evt.log. It includes records from 0122 through 03f5 but doesn't show the 0dff records or beyond (before the SEL was cleared). It looks like we don't have enough evidence to find out what went wrong in this instance.
Noted, with thanks!
getevt exits with return code ( rv = -3)
Apparently this was attributed to the MS IPMI driver issues, and was resolved with the Intel driver.
ipmiutil sensor not working for Huawei or DELL hardware (driver)
ipmiutil sensor not working for Huawei or DELL hardware (driver)
ipmiutil sensor not working for Huawei or DELL hardware (driver)
The ipmiutil package is compatible with any IPMI-compliant firmware/hardware. I see that you are running Windows, so either the Intel or Microsoft IPMI driver is a prerequisite. See ipmiutil UserGuide section 5.1 https://ipmiutil.sourceforge.net/docs/UserGuide. Due to some unresolved bugs in the Microsoft driver, the Intel driver is preferred.
ipmiutil sensor not working for Huawei or DELL hardware
Hi, this is only a debian bug. It can closed here. CU Jörg
Apologies Andy, The above file may not be helpful in your debugging. I had to clear old-sel logs as free records were zero. I have attached the ipmiutil_event.log , that was captured earlier. See if it helps.
Apologies Andy, The above file may not be helpful in your debugging. I had to clear old-sel logs as free records were zero. I have attached the ipmiutil_event.log , that was captured earlier. See if it helps.
please find attached.
SMBIOS entry point
ipmi_cmd (GET_SEL_ENTRY) returns response with incorrect id.
Could you provide the 'ipmiutil sel' output (without debug) from this system, so that I can see the record ids in order?
ipmiutil command resturn error -3
To avoid this issue, you could load one of the IPMI drivers. For the BMC timeout with the driverless method resulting in -3, ipmiutil is recovering from the BMC timeout as well as can be expected and the retry succeeds.
Invalid data field request error
Fan speed sensor is not able to come back to OK state
Thanks for your response, Andy.
What you describe implies that the firmware has the fan sensor locked in that state until a reboot or power cycle. This may be on-purpose, i.e. persist the threshold to force attention to it, or it may be a firmware bug. The software (in this case ipmiutil) is reporting the state that the firmware sets. So this would be a question for the firmware vendor.
That makes sense. Thanks for doing the research to present it this way. We would need to leverage /sys/firmware/efi/systab (in Linux only, not Windows, other) to support this method.
SMBIOS entry point
Fan speed sensor is not able to come back to OK state
Thank you for your response Andy, But, No, that was not the case, if you observe below log closely get_sel(0) rv=0 cc=0 id=b4 next=2200 sel ok, id=0 next=2200 we are requesting recid= 0, usual response should be 1 or ffff, but why 2200? ( as there was no SEL log identified by 2200, when this log happened) and in the below log get_sel(dff) rv=0 cc=0 id=dff next=7 sel ok, id=dff next=7 recid is dff, the next record is supposed to be e00 or ffff (LAST_REC), but why is it going back to 7 and relogging...
Thank you for your response Andy, But, No, that was not the case, if you observe below log closely get_sel(0) rv=0 cc=0 id=b4 next=2200 sel ok, id=0 next=2200 we are requesting recid= 0, usual response should be 1 or ffff, but why 2200? ( as there was no SEL log identified by 2200, when this log happened) and in the below log get_sel(dff) rv=0 cc=0 id=dff next=**7** sel ok, id=dff next=7 recid is dff, the next record is supposed to be e00 or ffff (LAST_REC), but why is it going back to 7 and relogging...
OK, this seems to be occurring when the recid requested is a large number (e.g. 2200) but in the interim, the SEL has been cleared, so the current last recid is smaller (e.g. 0144). It sounds like we need a method for getevt to notice that the SEL has been cleared and reset its last recid. If the getevt service were restarted, it would get back to normal, but it needs to self-correct.
ipmi_cmd (GET_SEL_ENTRY) returns response with incorrect id.
Issues with windows msi installer
After uninstall - wrong path Ouch. I need to build a new one with that fixed Problem with 2 eay dll files This works if installed as administrator and those 2 DLLs get put into Windows\system32, but could fail to copy those if the install user does not have write privileges to system32. The right answer is to change it to copy the 2 DLLs into the ipmiutil directory instead.
Issues with windows msi installer
Yes, the -3 error is showing that there was no response from the BMC within the timeout (300ms). This usually means that the BMC was busy with some event.
Hi Andy, Thanks for the response. Here by the firmware you mean BMC firmware? so does that mean error is coming from BMC side? Thanks Arvind
ipmiutil command resturn error -3
Notice that it first tries to open the OpenIPMI driver, then the imb driver, then the direct/driverless method. Using one of the drivers allows various software to access the firmware. The direct/driverless method depends on being the only client accessing the firmware. It will get errors if either some other program is accessing the firmware, or if the firmware is busy with an event. However, it has a loop to try again, and it succeeds when trying again.
ipmiutil command resturn error -3
Can't find SMBIOS address entry point.
So the bottom line is that this AMI CSM_Support setting appears to disable the server management firmware if it is set to disabled. Not much that ipmiutil can do about that.