Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
Followed that, installed it but when running it says no hostname specified! But i used the -N and ip address.
On the X11 boards, make sure you set fan mode to Optimal first. That will be default 30% PWM. It will ramp up from there, but never below 30.
The X11 gen is an oddball. X10 and X12 both require fan mode = FULL before trying to use IPMI to set fan speeds.
FWIW, "standard" = 50% and if your board has the "Heavy I/O" setting, it = 70% default.
The X11 gen is an oddball. X10 and X12 both require fan mode = FULL before trying to use IPMI to set fan speeds.
FWIW, "standard" = 50% and if your board has the "Heavy I/O" setting, it = 70% default.
Any ideas on an X11, when Optimal is not an option? I have a X11SAE Rev 1.03A that I can't get the fans lowered on. I have it set for "Standard Speed" but have tried Full Speed before sending commands. If I send a command to lower the duty cycle, it will lower for a second and then ramp right back up. It's a single zone and I am trying to configure one of the many scripts to work. Currently have the fans on Standard which is 8,800 RPM (37% Duty).
Anyone have any ideas or different IPMI commands I could try? Thanks!
The end result that I settled on was a batch file running continuously looping that repeatedly sends the command that lowers them (which you noted above works for second). They never get a chance to speed up as the command just keeps running. I was concerned what the long term effect of running this would be, but it has been running for nearly 8 months now with no issues. Because I am running Windows, I use IPMICFG-Win command line utility. I name the batch file Slow_Down_Fans.BAT and put a shortcut to it in the startup folder.
Code:
@echo off
:STARTHERE
IPMICFG-Win.exe -raw 0x30 0x70 0x66 0x01 0x00 0x10>nul
GOTO STARTHEREi found that on some of the less main stream boards that the fan commands wouldnt stick, more specifically: model boards that were in the same generation, but didnt share the same chipset, so for example: X10/X11 boards that are NOT C612-based X10 E5 2600 or C621-based X11 Scalable, and i'm going to guess that it's the same for this board.
i observed the same behavior on X11SSW-F which shares the same platform as your X11SAE. fan commands wouldnt stay no matter what. didnt find any fixes or insight out there sadly. my hunch is that the ipmi firmware for C236-based is implemented is slightly different for whatever reason
Apologies for my delayed response... travelling the last few days. The answer is: your board (X11SAE) does not support manual fan control via IPMI. I suspect it's the middleware that is the culprit (not allowing the request to be passed through to the BMC chipset). This may be because SM considers this a workstation board. It also appears (from reviewing the manual) that there are 5 fan headers, all of which are in the CPU cooling zone.
It's a bit unusual since the BMC is an ASpeed AST2400. However, as I mentioned, I suspect it's hard-coded in the middleware to ignore IPMI commands addressing the fan controller since this is a workstation board. Based on your description of the server's behavior, I'd surmise the BIOS is configured to ping the BMC with fan control messages periodically. The BIOS chip might be directly connected to the BMC chip. If all of this is true, it would support the behavior you're observing. The BIOS might also by-pass the BMC completely and talk directly to the physical fan controller, but that is very unlikely with a gen 11 board.
On dedicated server boards with the same BMC chip, it's more common for both the BIOS and side-channel (e.g. IPMI) fan instructions to be routed through the middleware, and then only the middleware (e.g. Redfish) talks to the BMC with regards to fan control. This is how it's possible to get the BMC to ignore any requests from the BIOS. The middleware acts as the gatekeeper. Another variation is when the BIOS only sends the fan speed command once - on startup - directly to the BMC or fan controller, and does not try to affect it again unless it has temp sensor algos that get tripped for one reason or another. However, in more modern boards this is less likely as it cuts the middleware and potentially the BMC chip itself out of the loop with regards to communication, which can then in turn lead to conflicting commands being sent to the BMC and fan controller. It's much cleaner to have all the commands routed thru the middleware and/or hard-coding some of them in the BMC itself (e.g. upper / lower fan speed thresholds).
As a user it's often very difficult to tell exactly how the fan control path works on any given board, but the end result is the same.
Thanks for the reply... I suspect you're correct, although I did have my part numbers mixed up. I was looking at a mobo picture from another server. The one I'm having issues with is the X11DSC+, but I suspect it's the same issue you outlined above... It uses the ASPEED AST2500 IPMI.
I logged in to IPMIView for the first time and noticed there is no Redfish version
Any ideas for how I could bypass the IPMI or BMC? This motherboard only has one zone, with the 5 fans. I would have thought with it having 24x 3.5" drive bays and dual CPU's, that it would be separate zones, but it's not. What are my options?
Would I be better off installing some new fans, powered off of another power source instead of the motherboard fan headers? I'm not really sure where to go from here. Thanks for taking the time to write up your detailed response, I appreciate it.
Attachments
Last edited:
bgrorud's solution is the only thing that worked for me on my X11DSC+. The following script is running on my truenas scale server and it is keeping the fan speed under control. Without the loop, the fan speed only drops for a second before returning to the standard speed.
Bash:
# Set fan mode to normal
ipmitool raw 0x30 0x45 0x01 0x00
# Loop indefinitely to run the ipmitool command
while true; do
ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x14
# Optional: insert a sleep interval (in seconds) to avoid overloading the system
sleep 0.25
done