So glad I found this thread. I've been trying to troubleshoot a fan control issue with Intel for the last several days with no solution. Started after I updated my BIOS to 0156.
I have this board and 2 4-pin PWM fans, a CPU and a System fan. After updating my BIOS to 0156 my system fan no longer would vary its speed based on temperature and PWM control. It was stuck on at 100%. My CPU fan was fine. I ran through a number of troubleshooting steps with Intel and still it was stuck at 100%. Even rolled back to the previous 2 versions of the BIOS and still stuck at 100%. At that point we thought it was a system fan header hardware issue.
Interestingly enough I then downloaded SpeedFan and discovered it did properly change fan speed on my system fan. So that led me to believe that it very well could be a BIOS/software issue. Then found this thread.
So I used the recover method to go back to 0155 but that didn't quite do it. What did it was changing my LABEL on my fan (a poster in this thread led me down that path) to a different label. I rebooted and PWM was working again. I then changed it back to my original label and PWM BIOS control was still working.
So I'm back to 0155 with 2 working PWM fans. But changing the label seemed to solve it for me. It's possible that might also work with 0156 but at this point I don't want to chance it not working again. But very odd that a label change got it working again. Maybe the change itself cleared a setting that was keeping it 100% on. Strange.
Here's that I can tell you...
First some background: The Environmental Monitoring and Fan Speed Control (FSC) software stack utilizes a configuration control block that is stored separate from the BIOS's configuration control block. This is to facilitate the stack obtaining the configuration in runtime environments (such as Windows*). When you change a parameter (either via BIOS Setup or Intel(R) Integrator Toolkit (ITK)), the BIOS must copy the appropriate information to this separate control block. The same thing must happen when applications (like Intel(R) Desktop Utilities (IDU)) make changes to the health thresholds.
Now the situation: Somehow, during the BIOS update process, the FSC configuration control block is getting corrupted with bad data. The FSC software is seeing that this is the case and it stops its initialization of the fan speed control hardware as a result (hence the reason why some or all of the fan controllers are stuck at 100% duty cycle; this is their power-on default). We do not know why this problem is occurring. Our attempts to reproduce this in the factory have all failed; it simply isn't happening for us. We continue to attempt to reproduce it, however...
Workaround: Forcing the BIOS to update the FSC Configuration control block is all that is required. This can be accomplished in many ways, restoring the BIOS configuration to defaults or restoring only the fan speed control configuration to defaults is usually sufficient. Changing the label - or any other parameter, for that matter - should also accomplish the same thing (any change will cause the BIOS to rewrite the entire FSC configuration control block). I just want to make sure that you understand that a change to a Usage parameter - the "label" as you call it - in and of itself is not fixing anything; it is the side-effect of the control block being written that is accomplishing it. Changing the Usage parameters makes to material difference to the fan speed control configuration; they are, as you say, nothing but labels; they are there to help applications (like IDU) identify how fans and sensors are being used within the system...
As I said, we are continuing to look into why the corruption is occurring. In the meantime, you have this workaround to get you back to where you need to be. Sorry for the inconvenience...
Thank you for your response clarifying and acknowledging the issue. I'm glad to hear that Intel is aware of the issue and is attempting to fix it. It's been a difficult issue for me to try and troubleshoot, with Intel's help, over the last several days. Your explanation makes alot of sense in terms of what is happening.
A few comments on your workaround suggestion. This may or may not help as you investigate this further.
- Restoring the BIOS configuration to defaults did not fix the issue for me when I was troubleshooting and trying to restore PWM control to my system/chassis/outlet fan. I did this many times. I also changed values in the fan configuration. Went from automatic to manual, different duty cycle settings and back to defaults. None of these fixed the problem. Not sure why. Yet the fan connected to the CPU header always worked under PWM control no matter what changes I made to settings or BIOS.
- This issue arose when I updated the BIOS to 0156. I subsequently rolled back to different releases prior to 0156 and again adjusted fan control settings and the system fan stayed on at 100%.
- While I was still troubleshooting and trying to fix the problem I did discover that an alternative fan control application, SpeedFan, did work properly which got me thinking it was a BIOS/SW issue again and not a hardware/header issue.
- I rolled back one more time to 0155. Again the problem remained even if I changed to defaults or adjusted fan control duty cycle settings. It was only when I changed the usage label (there was a clue to this effect in another post on the Intel forum) that I regained PWM control. I understand that what ended up happening was a complete rewrite of the configuration control block. But for whatever reason this did not happen for me in my case via restoring defaults. Only the label change made the difference so for me that was the only thing that would flush/rewrite the configuration control block.
So for now I'm staying with 0155. It sounds like it could potentially work with 0156 but I'm not willing to risk it again at this point as my fan control is working exactly how I want it to.
I can confirm two cases of 156 causing the case fan to run at 100%. I'd been using a DH67CF for a year with the stock i3 cooler and a Gelid 120mm PWM case fan. It was so quiet I couldn't hear the system running. Something happened and the board went dead. I RMA'd it and the replacement board shipped with BIOS rev76. I didn't take note of the system noise. First thing I did was update to the latest BIOS which was rev156. The case fan only, not the CPU fan, went to 100%. I swapped the two fans' connectors and the stock cooler went to 100% on the case fan header. I RMA'd this replacement board thinking it was defective.
When board #3 arrived it shipped with rev76. This time I noticed that the system ran nice and quiet. I updated to 156 and it got loud again. I couldn't believe it. Now that I knew it had to be a BIOS issue I searched and found this thread.
I can concur that dropping to 155 alone did not fix the issue. In one visit to the BIOS, I loaded defaults and changed the fan label to Chassis. As soon as exited saving changes, the noise dropped. I'm back to where I should be.
I tried all of the reset/change label tricks on 156 and nothing helped. I had to go down to 155 before I got relief.
Scott, thanks so much for acknowledging the issue here. It is the only reason I am still planning to buy the new itx H77 board for my next build.
I too have had the problem with the case fan running at 100% after updating my DH67CF to V1.56 from an earlier version (1.3x?) and clearing the FSC configuration block as you suggest has NOT fixed the problem.But I do have some info which may help you tracing the bug.
Before the upgrade, I was using Speedfan to monitor fan speeds, temps etc, but control of the fan speeds from the windows software was (as you would expect) disabled since the BIOS fan speed control was enabled-
After the BIOS update, the case fan ran at 100% but speedfan was now able to control the case fan speed despite the BIOS speed control (supposedly) being enabled! As before speedfan could not control the CPU fan speed, which continued under BIOS control.
The BIOS is now labelling the case fan as "Outlet (Rear Fan Header)" and is reporting the correct speed (full) but the BIOS control is inoperative.
Speedfan is reporting the Rear Fan Speed as zero, and does not offer any fan speed control for this. It is reporting the case fan speed as the FRONT fan speed and it is this which it is able to change the speed of.
From my days as a software developer, it looks to me as if the v 1.56 BIOS is controlling the wrong fan header (one that is not present on the DH67CF), hence allowing Speedfan acess to control the correct header!
First of all, let me correct a few misconceptions...
Once the BIOS relinquishes control to the bootstrap loader for the O/S (Windows, Linux, whatever), it is no longer involved in the fan speed control decision-making. The SIO devices that we use on our motherboards are capable of independent decision-making; the BIOS simply configures this capability to garner the desired thermal/acoustic results and lets it go. We chose what SIO devices we use on our motherboards based upon capabilities and cost. My input to this process is with regards to the sophistication of the fan speed control capabilities included; I fight for solutions that, for example, allow me to involve multiple temperatures in each fan speed controllers' decision-making and that allow me to control the "shape" of the response curve used with each temperature, all so that I can optimize the thermal, acoustic and psychoacoustic results. I digress; the point is that the SIO is responsible for the actual decision-making; the BIOS simply tells it how to do this decision-making and then leaves it to take care of it...
Next, let's talk about SpeedFan. The SIOs all contain a capability that allows its fan speed control decision-making to be disabled (the programming is not lost; just suspended) and software can then tell the fan controllers what (manual) duty cycle each is to operate at. The BIOS typically has absolutely no control over this capability (some future devices I am working on will have security features to protect against this; the SIO devices used in this particular motherboard generation do not, however). Thus, there is nothing stopping applications like SpeedFan from "taking over" fan speed control decision-making -- other than SpeedFan's own understanding of the capabilities and registers of the particular SIO device being utilized and the design of the motherboard in question (i.e. which fan controller is used for what purpose, etc. and etc.). In general, Alfredo has done an excellent job of generically handling all of the SIOs that are out there (no small feat!) and SpeedFan has capabilities for recognizing particular motherboards and tailoring its operation to these motherboard designs. I feed a number of ISVs, including Alfredo, with information about our motherboard designs so that their applications can work well on our motherboards (I even seed them with boards and processors from time to time so they they can run tests directly and make sure they get it right -- though they will always tell you I don't do this often enough, of course)). There are times where this recognition breaks down, however, and the applications have problems with a board. I am unsure whether this is the case here; all I can say is that there is nothing that the BIOS is doing that can affect SpeedFan's ability to place the device in manual control mode -- and, as far as I know, there's nothing that could be changed from one BIOS version to another that could purposefully affect this cability...
The easiest way to see if an application fully understands the device and motherboard is to look at the voltage readings it is exposing. The ADC in the device that is used to "read" the voltages has a fixed voltage input range (typically 0 - 2.4V); any higher voltages - 12V, 5V, 3.3V, 3.3V Standby, etc. - must be divided down to fall within this range (this is done using pull-up and pull-down resistor pairs on the motherboard). When software reads the readings from these sensors, it has to know what divider was used on the motherboard and thus what multiplier it has to apply in order to return the reading back to the appropriate range. Thus, if you see voltage readings that the software is not multiplying up to the appropriate range, you know that the software likely doesn't have the understanding that it needs. You can use readings from BIOS Setup or the Intel(R) Desktop Utilities application for comparison purposes for this...
In my previous email, I mentioned that resetting the BIOS to defaults will force the FSC configuration variable to be re-written. This isn't always true; if you have not changed any settings, resetting to defaults won't identify any parameters that (now) have differences to be applied and thus the variable won't get updated. To be absolutely sure, you need to change something - a fan usage or a temperature threshold or something like that. You can alway change it back after a reboot or two.
Ok, let's talk about this particular problem. It happens that I used a DH67CF board for my own HTPC, so I have a board to play guinea pig with. I loaded the BL0156 BIOS onto my board (I was a "few" versions down-rev myself; some example I make) and... everything is working just fine; no glitches in fan controller assignments, no problems with sensor readings and certainly no fans running at 100%. So much for catching a simple case. I wil continue to look; if you can tell me an exact BIOS version that, going from it to BL0156, causes the problem to occur (and is hopefully repeatable), let me know...
Yes, I have seen this thread (and the 3 or 4 others that are similarly talking about this same symptom). Unfortunately, we have been unable to reproduce this issue ourselves (it doesn't happen when we try it). Until we do so successfully, we aren't going to be able to figure out what is wrong and fix it. I wish I had a better answer, but that's where things stand...
here are the steps I can reproduce this issue on the DH67CF:
Steps 2.-5. are also necessary when I´m downgrading from 0159 to 0155 again.
From now on my rear-fan ist running quite with a 30 % duty cycle.
6. Now I´m upgrading to 0159 with the F7 method using the file BL0159.BIO
7. After BIOS-upgrade, the rear-fan is still running with a duty cycle of 30 %, but adjusting the duty cycle to another value has no effect
8. Go into BIOS and select "Exit->Load BIOS Defaults", "YES"
9. Select "Exit Saving Changes", "YES"
10. The rear-fan is still running with a duty cycle of 30 %, but adjusting the duty cycle to another value has no effect
11. Go into BIOS and go to "Configuration->Fan Control & Real-Time Monitoring"
12. Select "Restore Default Fan Control Configuration", "YES"
13. Exit and save the changes
14. From now on, the rear-fan is running at 100 % and the only solution is downgrading to 0155
Let me be clear, so you won't waste any more time upgrading/downgrading your BIOS for all the wrong reasons. I do not believe that the issue is (necessarily) a bug in any particular BIOS release; I believe that the issue is occurring during the BIOS update process and will propagate forward -- or backward -- once it is in existence. Bottom line, don't waste your time downgrading to an older BIOS if this happens to you; it isn't the current BIOS's fault (well, per se)...
First, some background. The software that implements the initialization of the hardware device(s) that are used for monitoring and fan speed control does so based upon the contents of a secondary data structure. This methodology is used to support runtime software making changes to the configuration. During POST, the BIOS is responsible for synchronizing its BIOS Setup parameters with the parameters within this data structure; moving runtime changes into the BIOS Setup parameters or moving BIOS Setup parameter changes (whether made in BIOS setup or via a tool like Intel(R) Integrator Toolkit) into this data structure...
I believe that, during the BIOS upgrade/downgrade process, the BIOS Setup parameters and the Fan Speed Control (FSC) configuration data structure are getting out of sync with each other and that (perhaps) some sort of corruption is occurring within this data structure (causing hardware initialization to be incorrect/incomplete). Unfortunately, every time I try to reproduce this myself, it works perfectly for me; there is something in the process - or some difference in the environment - that I am missing. I have tried this on multiple different boards and multiple times on an individual board. This could be something in hardware (unlikely but I can't rule this out completely), something in the BIOS configuration (perhaps even something logically unrelated to FSC) or something in the process methodology/implementation (step ordering, etc.). If you want to provide me with more information about your system or the upgrade (or downgrade) process you followed, you can do so via private message to me.
To fix this issue, you need to force the BIOS to rewrite this data structure. How do you do this? First of all, doing a FSC-level Restore-Defaults or doing a full BIOS Restore-Defaults is NOT guaranteed to cause the data structure to be re-written (it might work, but as some folks have said, it doesn't for everyone). If I had been asked a week or two ago, I would have said that all you needed to do was make a change in the configuration - change one of the fan's Usage values or one of the health thresholds for one or the temperature, voltage or fan sensors - but folks have tried this and there have been some cases where this didn't fix the problem -- but, while I investigate further, try this; it has the biggest chance of success...
I already followed the instructions you gave in this thread, but the only thing which worked for me, is the step-by-step list I provided above.
After upgrading to 0159, the "Restore Default Fan Control Configuration" is the point, from which the rear-fan always stays at 100 %.
Only downgrading the BIOS to 0155 (0156 does not work) and "Restore Default Fan Control Configuration" fixes this isue for.