Activity for Andy Cress
-
Andy Cress modified ticket #61
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?
-
It appears that the firmware will not accept a lanplus connection session. There are two possible causes that I can think of: 1) This firmware only accepts IPMI LAN 1.x and not LAN 2.0 (lanplus), which seems unlikely but is easy to check by adding option "-Flan" 2) The IPMI LAN configuration is incorrect on that server somehow. Running 'ipmiutil lan' and 'ifconfig' (or ipconfig) locally on the 192.168.1.171 server will show all of the configuration parameters for review.
-
Hmmm. I'm surprised. This is Intel firmware on the Intel S4600LH motherboard. BMC manufacturer = 000157 (Intel), product = 005c (S4600LH) BMC version = 1.15.4159 (Boot 1.13), IPMI v2.0 BIOS Version = SE5C600.86B.01.07.0002.030620132047 That means this isn't a one-off behavior, so ipmiutil needs to handle it more robustly. I guess the best approach then is to modify igetevent.c to initiate a new session for each pass.
-
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...
-
It appears that the firmware will not accept a lanplus connection session. There are two possible causes that I can think of: 1) This firmware only accepts IPMI LAN 1.x and not LAN 2.0 (lanplus), which seems unlikely but is easy to check by adding option "-Flan" 2) The IPMI LAN configuration is incorrect on that server somehow. Running 'ipmiutil lan' and 'ifconfig' (or ipconfig) locally on the 192.168.1.171 server will show all of the configuration parameters for review. On Thu, Feb 3, 2022 at 3:08...
-
getevt exits with return code ( rv = -3)
-
That error means that the receive failed (LAN_ERR_RECV_FAIL = -3 in ipmicmd.h). There are several methods to get the events, mainly the SEL_events method and the GetMessage method. This by default uses the SEL_events method, and should continue to read the last SEL event until a new event occurs. The fact that it fails to read the SEL event that it was able to read twice before implies some firmware anomaly. Which firmware vendor is this? It may work better in this case to use -m instead of -s. If...
-
[supermicro] invalid DIMM location decoding from SMBIOS
-
This was included in ipmiutil-3.1.8: 11/05/2021 ARCress ipmiutil-3.1.8 changes (iver 3.18) util/oem_supermicro.c - disable DIMM decoding from SMBIOS for SuperMicro (albertlav)
-
IPMI memory issue
-
The ipmiutil-3.1.8 release was posted on 11/05/2021
-
Oops. This change did not get included in ipmiutil-3.1.8. It will go into the next release.
-
Issue starting ipmiutil.exe on Windows 10
-
ipmiutil.exe dependency
-
Yes, the two openssl DLLs (libeay32.dll and ssleay32.dll) must be in the PATH somewhere for ipmiutil.exe in order to support the lanplus protocol which uses SSL. This could be: - in \Windows\system32, - in the same directory as ipmiutil.exe, or - somewhere in the %PATH%
-
I believe so, but we won’t know for sure until you validate it.
-
ipmiutil-3.1.8 is released
-
Finally I got a fresh clean build of openssl 64bit and this should either run clean or give better debug. http://ipmiutil.sourceforge.net/FILES/ipmiutil-317q.zip (ipmiutil-317q64.exe and *eay32.dll)
-
Sorry not yet. I have been consumed with my day job. Planning for time to get it done this week.
-
That confirms that the error is in the openssl code, so I do need to rebuild/modify that. For several of these, you were able to do lanplus previously with ipmiutil-3.1.2. Is this one of those, or has this one never worked?
-
I built this one with just ipmiutil-3.1.2, and from previous discussions, that release didn't have any lanplus issues, so please see if that works for you. http://ipmiutil.sourceforge.net/FILES/ipmiutil312.zip
-
I have been thinking about this issue, and I think I have a different approach. I want to rebase with v3.1.2 to make sure that source works with the new build environment, then build from there.
-
I did find one place that it could return without the error being checked. It is odd that we get varying results on the same system. Here is an updated version to try http://ipmiutil.sourceforge.net/FILES/ipmiutil-317p64.exe
-
That was odd, it died inside oem_active, earlier than the last test. I added some additional checks in that routine, but I would like this run with from the same directory as the DLLs from test.zip for consistency. Here is the updated one http://ipmiutil.sourceforge.net/FILES/ipmiutil-317o64.exe
-
OK, we are getting closer. This should get further now, or perhaps run clean. http://ipmiutil.sourceforge.net/FILES/ipmiutil-317n64.exe
-
I'm sorry this is taking so long. I have been pretty busy with other things. Thank you for your willingness and persistence to pursue this. The fact that it completely opened the session and then dies is a real puzzle. It looks like it is ready to send the first command (SetSessionPriv), but dies in the middle of outputting a debug message. I have revised that next debug message and added more debug to see where it goes next. Can you try this one? http://ipmiutil.sourceforge.net/FILES/ipmiutil-3...
-
Ok, try this http://ipmiutil.sourceforge.net/FILES/test.zip If the *eay.dll files are in the same folder, they will override any in the windows\system32 directory
1 >