Activity for Andy Cress
-
Andy Cress posted a comment on ticket #12
This project has been released since 2001, so it is interesting that this hasn't been an issue until now, but I understand that libtool for RHEL would not be a fit for Debian. It does pose some issues from my end though, because I have now retired and my infrastructure to build and test all of the various OS versions is limited. In any case, let's see what can be done in the near term. The official current source tarball is always at http://sourceforge.net/projects/ipmiutil/files/ipmiutil-3.2.2.tar.gz...
-
reset: interpret -e as a modifier, not a target
-
Fixed in ipmiutil-3.2.2
-
reset: target behavior differs depending on the ordering of command-line options
-
Fixed in ipmiutil-3.2.2
-
reset: enhancement: add -l<num> option for reset/powerup to a specific internal logical instance
-
Fixed in ipmiutil-3.2.2
-
ipmiutil-3.2.2 is released
-
reset: enhancement: add -l<num> option for reset/powerup to a specific internal logical instance
-
reset: target behavior differs depending on the ordering of command-line options
-
reset: interpret -e as a modifier, not a target
-
Thank you for the detailed information, and for the patch. I see why this change is needed.
-
ipmiutil alarm/health not working on Windows
-
From Nov 21, 2024 email thread: I really don't have any good answers to resolve this. A few things that you could do: - use version 3.1.8 if that suits you best for this case - investigate the firmware side to see why it appears to return extra bytes for the HMAC - use the new version with -Y Also note that there have been several openssl DLL version upgrades, so the latest (ipmiutil-3.2.1) should have all the current fixes.
-
failed to build 3.1.9 for macos sequoia
-
I have included this in iipmiutil-3.2.1, just released. This works for me, but let me know to confirm that you don't have any issues with it.
-
avoid tampering with TMPDIR
-
Now included in ipmiutil-3.2.1
-
libipmiutil underlinked against libcrypto
-
OK, I have updated the ipmiutil-3.2.1.tar.gz to include -lcrypto in the library build.
-
avoid tampering with TMPDIR
-
I have applied an update that should resolve this in ipmiutil-3.2.1 (does not set TMPDIR), but would like you to confirm it before pushing this out. Here is the updated tarball - https://ipmiutil.sourceforge.net/FILES/ipmiutil-3.2.1.tar.gz
-
avoid tampering with TMPDIR
-
Sorry for the delay in responding. I remember doing an update for this ticket, and I believe that the change was included in 3.1.7 and beyond, but it isn't enumerated in the Changelog.
-
This was included in the ipmiutil-3.2.0 changes released 12/05/2024, and also in github.
-
Yes, I'll do that shortly. Sorry that I missed including that previously.
-
failed to build 3.1.9 for macos sequoia
-
Attached is the updated oem_dell.c Yes, there was an updated library file added in 3.1.9
-
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.
-
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
-
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...
-
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
"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.
-
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?
-
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...
-
"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:...
-
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.
-
getevt exits with return code ( rv = -3)
-
ipmiutil sensor not working for Huawei or DELL hardware (driver)
-
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)
-
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
OK, so apparently this "CSM_Support" setting controls all of the Server Management firmware stuff. So when it is turned off, the IPMI driver cannot load, because the firmware is disabled. Nothing we can do about that. Out of curiosity, who is the BIOS/platform vendor that has this setting?
-
The SMBIOS part in util/mem_if.c is looking for the string "SM" in the physical memory starting at 0xF000. Perhaps disabling CSM_SUPPORT affects this (?). However, the key issue appears to be with the IPMI firmware. You don't have a driver loaded (best option), but ipmiutil would have tried to use driverless, which would be sufficient if you are running as root. Driverless is intended for maintenance (single user) mode. Two questions: 1) Did this work OK before you disabled CSM_SUPPORT in the BIOS?...
-
The SMBIOS part in util/mem_if.c is looking for the string 'SM' in the physical memory starting at 0xF000. Perhaps disabling CSM_SUPPORT affects this (?). However, the key issue appears to be with the IPMI firmware. You don't have a driver loaded (best option), but ipmiutil would have tried to use driverless, which would be sufficient if you are running as root. Driverless is intended for maintenance (single user) mode. Two questions: 1) Did this work OK before you disabled CSM_SUPPORT in the BIOS?...
-
getevt exits with return code ( rv = -3)
-
ipmiutil.exe dependency
-
Question answered. Problem resolved
-
if we do not get a response with the above information by 6/30, we will assume that Pankaj resolved it via step 1 or 2 above.
-
The show_fru() stops printing in the middle of processing Board Info area with a single byte data for a field
-
Resolved the issue. The FRU data is ok now. No change to ipmiutil is warranted.
-
Actually, the 0xC1 is empirically the end of the FRU data. Keep in mind that the length portion of this byte (0x01) includes the current byte. So if there were a one byte FRU data field with 'x', it would be 0xC2 0x78. There are several firmware vendors who have garbage after the FRU_END byte, so it is needful to exit the loop when 0xC1 is encountered. Over the years, several firmware FRU data flaws have been handled via ChkOverflow() and ValidTL(), but the FRU_END 0xC1 cannot be changed. Also, the...
-
In the 3.1.8 code, when the isensor module exits, it always frees the SDR buffer that was allocated. I notice that your screenshot shows memory being left only sometimes. I'm wondering if perhaps the 'ipmiutil sensor' code is being killed or aborted in those cases before it can free the memory. We do know that MS Windows has gotten worse about memory cleanup with the later versions. 1) I'm wondering if there is a Windows function that we can configure to be called when a kill/abort event occurs,...
-
Coming back to this, you have probably already handled it, but you have a few alternatives: 1) Contact the OpenIPMI driver project to resolve the slowness with kernel 5.4.0. 2) Create a bash script to run the ipmiutil sel via driverless with only one session, which would need to save the last event, and only take action if the last event does not match the saved event (i.e. one or more new events). 3) In ipmiutil, we could create an option to igetevent.c which would cause it to create a fresh session...
-
For this function, it looks like the right approach is fixing the firmware on this motherboard. The command 'ipmiutil health -x' will show the make and firmware version from the get_deviceid function as hex codes, and will show known makes. The firmware version is 1.15 as shown above, but the make/manufacturer isn't shown by default. However, to enter a support request you will probably have to go through the server manufacturer. The problem is that the firmware doesn't handle more than 2 requests...
-
Invalid data field request error
-
Since this seems to be specific to that firmware, we need more information. 1) What happens if you try this with -Flan instead of -Flan2? 2) Can you get the IPMI LAN configuration from the server at 192.168.1.171? Do you know which firmware vendor it is?
1 >
