Rem0o
commented
2 years ago As soon as you shutdown your computer, your bios resets all the settings. FanControl is an override, it doesn't change any underlying setting in your bios.
Closed saynotocode closed 2 years ago
Rem0o
commented
2 years ago As soon as you shutdown your computer, your bios resets all the settings. FanControl is an override, it doesn't change any underlying setting in your bios.
saynotocode
commented
2 years ago hmm, ok. Do you have any idea what i might have done to cause it to act this way? Should I re-flash the bios? Kind of having trouble understanding what it's doing with the fans going crazy and all. Sorry to assume it was fancontrol that did it. It's just that it started acting weird after I installed it.
Rem0o
commented
2 years ago That's on your end, I don't have your motherboard so I can't diagnose for you how your bios acts with your fans and all. In doubt, a reset might get you on track.
TDZHDTV
commented
2 years ago I can confirm I had the exact same issue after a partial setup procedure with this program, no amount of restarts, Bios update would resolve, I finally got back to normal fan speeds by holding down my power button for 10 seconds. I not sure when entry the setup process installed but it sent my Cooler fans off like a jet engine.
saynotocode
commented
2 years ago I've been doing some more troubleshooting and this issue definitely seems real. There is some register that fan control is accessing on this motherboard that is not closed properly when restarting and this causes the bios fan control to act possessed. Under bios control the fans (all of them) will ramp up and down from zero to max rpm every second or so. My system has six noctua pwm fans and the noise they make when it does this is troubling to say the least. This will persist over countless restarts of the system and the only way to alleviate it is to power down the system and then boot up again. This will bring the bios control back to normal. It took the longest time to figure this out as i tend to never fully shut down my system.
So i took your advice that it may be the bios. I rolled back to a previous version, reset to optimised defaults, cleared cmos. I tried removing some of the fans from the system, thought at one point that my fan hub was the cause so removed that. Eventually I decided to do a clean install of windows, nothing but the chipset drivers, some network drivers, hwmonitor and fancontrol, note i did not install any of gigabyte's crapware. If i start fan control and configure it, then restart my system the problem appears. However if I boot the system, run fancontrol, then exit fancontrol before restarting the problem DOES NOT APPEAR!. There is definitely something fancontrol is doing that upsets gigabytes smart fan 6 bios settings.
I also tried on another system. My son has a 5 month old i5-11400f gigabyte b560m auros pro, case fans are voltage, cpu cooler is pwm with two fans. installed fancontrol, configured, ran for a bit, restarted. This system was acting the same. Shut down, then boot, the problem goes away. Once again if I run fancontrol, and later exit fancontrol before rebooting the problem does not appear.
Now I've ruled out many variables, bios version, fan hub, fans, windows version. The only factor that may be affecting these results now is that both these systems are dual booting windows. I'm unsure whether this would be affecting the results though. Could you please look into this issue some more? The way that the fans act when they become 'possessed' is a little disturbing, especially after spending so much on my expensive cooling. There will be a lot of gigabyte users that will hit this issue now that your software is getting some good publicity (congrats on that by the way).
Sorry to write so much here but wanted to convey that your software is great but this issue is extremely frustrating.
Rem0o
commented
2 years ago @saynotocode I don't know really how to tackle your problem. You got to understand I use this as a backend to access and control fans: https://github.com/LibreHardwareMonitor/LibreHardwareMonitor
This handles hundreds of different boards and try to put a common API in from of all of them. Fans are controlled via a SuperIO chip. The BIOS also accesses that chip to do it's fan control. They can both fight for that same "resource." FanControl does NOT messes with the bios, only the SuperIO chip. When FanControl tries to take control, it sets the channels on that chip to "software mode", aka manual, and then push values to it every second while the program is running. When you reboot, sleep or whatever, that chip resets to default, then the BIOS will push it's config on it. Those chip don't have any non-volatile memory AFAIK.
Now, I don't have your motherboard to do some testing or investigating. How do you expect me to be able to do anything in this case? That's the goal of using an open-source library for hardware support/compatibility. 1 guy, aka me, can't have every motherboard on the market and test them all. It's a community effort, and individuals with any hardware can go in there and contribute improving compatibility with hardware they have hands on.
saynotocode
commented
2 years ago Look I get it, i work as a software developer as well, and if people came to me and said my software caused x and y issues but I was convinced that it didn't I probably would not be all that willing to act either. However, I have demonstrated that your software is actually causing this issue. It might be on a small subset of the hardware that it runs on, but with the jayz2cents video now at half a million views there is going to be more people hitting this issue. Literally dozens!
So you have to try and find what is causing the problem and drop the 'it wasn't me' attitude, which i will from now on refer to as the shaggy defence. You will also have to be prepared to warn people that have the type of hardware that is affected by the issue that it can occur, and how to rectify it. I've never seen a problem crop up that cannot be solved by restarts but is resolved by a complete power cycle, it's weird and probably gigabyte's micro-code is more to blame than anything. While on this topic I think you should re-architect this software so that you don't have to be an admin user logged in for it to work. There's a lot of use cases for headless systems and if your software ran as a service instead of as an admin user I think it would be a vast improvement.
There is some issue caused when the program does not cleanly shut down, demonstrated by the issue not appearing when I exit the software before restarting the system. So maybe look into what it is doing when you exit the software and implement a shut down process that covers these things. We can't see the code as this isn't really 'open source' so you have to do it. so maybe another scheduled task like the startup one, but for shutdown, to exit the program cleanly.
In other news, I've tested this on windows 11 as well and the same thing happens, this is on my son's i5 system. I also tried running it on my previous machine, i5-6600K, gigabyte z170x gaming 3 motherboard, and it didn't happen. so there's some consolation there that it may only be the intel 400(?) and 500 chipset mobos, but who can say?
Rem0o
commented
2 years ago Actually, the bit of code that matters in your case is open-source. It would be in LibreHardwareMonitorLib.
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor
The two methods FanControl use are SetSoftware and SetDefault. There is nothing more to it.
From that software, which you can run with a debugger on, set a manual % on all your fans by right-clicking on each of them, and try to see if you get the same behavior if you don't exit out of the software as you described.
saynotocode
commented
2 years ago I've been trying with the release version of LibreHardwareMonitor to adjust the fan speeds and restart to see if the problem appears. It doesn't so far. What I have noticed is that the function to change fan speed only allows a fixed number in the ui, 5% increments, and that you are only able to change the setting once at a time. Maybe the frequency of speed changes and the granularity of the changes, (the ability to set fractions of percentage, eg 34.65% ), could be factor in introducing the issue.
However, i doubt that any of that is the issue, as I have been able to avoid the issue by exiting fancontrol before restarting. It may be that when the application is shut down it correctly disposes of the LibreHardMonitorLib.dll and does garbage collection appropriately. This may be the cause of the problem, but I'm just guessing here.
I'm going to try some more experimenting with LibreHardwareMonitor to see if i can invoke the issue, but I don't have much confidence that it will. As for running it in the IDE, i don't think I will be able to replicate the issue as visual studio will close the solution correctly if i attempt to restart my machine while it is running.
So once again, it is something that, so far, only your software is doing and you need to look at possible reasons as to why it is doing this.
Farlarzia
commented
2 years ago Hi there.
I'd like to add a second report of this behaviour after installing and running your software - after restarting my computer, while the software was active, I had an issue of the fans continously ramping up and down very loudly, endlessly. I did manage to resolve it using the technique saynotocode mentioned, and I will again below, but it was extremely annoying trying to trouble shoot why this was happening. Unfortunately, I haven't been able to replicate this since, despite some efforts. Perhaps it was some of the first time initialisation problem or such?
I'm not much of an expert when it comes to computers past being able to use google somewhat competantly, so I can't say much apart from my specs, and a few relavent details, of which saynotocode also reported.
Mobo: Gigabyte x570S Pro AX Rev 1.1 Bios revision: F4a CPU: Ryzen 5800x GPU: RTX 3080 FE OS: Windows 10 N, version 21H2, build 19044.1682
Pressing restart within windows did not resolve this - throughout the entire post, editing bios settings, boot, all the way until I start this software again, the issue persists. During this time, no other fan control software I had, either BIOS based, or SIV (the meh control software my BIOS recommended to install), can override this behaviour, instead just trying to fight the fans endlessly cycling up and down.
Otherwise to prevent this, I had to fully shutdown, and manually turn my computer back on, after
I'd love to be able to daily drive and recemmend this software, as when its actually running, its flexibility and control parametres are excellent, so hopefully this can be resolved.
Also while typing in this thread, albiet unrelated, I will also mention that your software was unable to find a controller for one of my fans (the other previously mentioned softwares had no issue regarding this), but the fan was still listed, and reporting fan RPM, correctly. Strange.
saynotocode
commented
2 years ago @Farlarzia It's real interesting that you've got the same issue on a gigabyte AMD system. I guess this issue is not confined to the Intel 500 series chipsets. @Rem0o seems to have decided that he can't be bothered to fix this, and that he didn't make it happen. In my troubleshooting I found that the issue will persist over many reboots etc. It seems you are experiencing the same.
The dev suggested the problem stems from LibrehardwareMonitor and that I try that software to invoke the issue. No luck there though. What I did find was another fan control software, suspiciously similar to this one (except actually open source), that will create the exact same behavior as FanControl. Could I ask you to try it? - https://github.com/lich426/FanCtrl in an attempt to see if it also creates the same issue on your X570 system.
It bothered me that the developer here doesn't seem willing to help rectify this issue, and that the software is not open source. Seeing the exact same issue present itself in this other software, which also has some similarities to this one made me start to think that Rem0o simply took the source code from the lich426 program (it is open source with GNU general public license v3.0) and slapped a nice material design GUI on it and is distributing it on Github as a donationware package. To do so would be against the license of the source code of lich426's work. If you know anything about the GNU general public license v3.0 it clearly states that any derivative works based off the original source code must also carry the same license and open source traits as the original.
So Rem0o, come on down here and prove that you didn't steal lich426's source code and package it up as donationware against the terms of the original author's license.
The similarities i found suspicious in the lich426 software are as follows.
Rem0o
commented
2 years ago @saynotocode
Woah dude, seems like you derailed quite a bit from the original issue there. I don't understand why you keep making heated claims over this software and myself. I'll stay factual.
Fact : it doesn't work fine on your system, that's sad, but without having your exact setup at home, I can't be debugging the behavior you described. No amount of "FIX THIS" attitude you are throwing at me will change that. Seems like a very low-level issue, and I can't see any obvious place in LHM or FC as to why this would happen without digging with the hardware in hand. I recommend you stop using the software, and move on. The problem most likely lies in the way LHM is implemented for your specific hardware.
Oh by the way, It's the same thing for any other hardware-specific bug people report to me, my answer is always the same: I can't debug hardware specific issues. Lookup all the closed issues on this repo.
Now about your juicy copyright claims, I'll answer them briefly because I find it funny if anything.
I'm aware of FanCtrl. Discovered it a while back.
Here is the original thread where I first posted FanControl. At that point, I was using it on my own computer for many months before, if you are curious. https://linustechtips.com/topic/1099996-fancontrol-my-take-on-a-speedfan-replacement/
The thread dates back before FanCtrl was first online, and FanControl used OHM/LHM from the start.
If anything, it might the other way around: FanControl maybe inspired his software in some ways, and that's fine. We kind of do the same things, but with "very" different approaches UI/UX wise. IMO, the more choices online, the better.
Of course he's using LHM, it's the only decent backend on Windows to do stuff like this on modern hardware. There ain't 5 ways to use that backend to control fans, so no surprise your bug is also present on that software: it's the exact same backend. If you started to work on a fan controlling software for windows yourself, you would most likely be ending with a very similar tech stack.
You noticed there are similarities in the way we handle stuff: maybe because we face the same problems? Start with windows must be delayed with LHM, otherwise it doesn't initialize properly. Similar problem, similar solution. Haven't read the code, but most likely he does the exact thing I do to set fan speeds also: have a clock call the "Set" method periodically on all fans with a given command.
Could go on and on, but you should get the point.
By the way, a hilariously blatant (real) copy I found is https://github.com/Nama/SuckControl. There might be more, who knows.
I think we went over everything, so don't mind if I close this for good.
saynotocode
commented
2 years ago Nice, close an issue not because you resolved it, but because you don't like what the user is saying. Fine, I could care less. However, the two other people who posted here about the same issue still haven't had it resolved either. Rest assured there will be other gigabyte users with this issue, but they may not see this post with troubleshooting results and, more importantly, the way to stop the fans acting crazy, because you have, 1- ignored it, and 2 - closed it without resolution.
Okay, I may have gone off the deep end with the accusations, and I'm sorry if that offended, but the way you have handled the issue speaks volumes.
You may well have developed your software before lich426, but at the end of the day, I and many others will trust an open source program, over the developer who claims he is keeping his software closed source 'for fun'.
As for SuckControl, what does that prove? It's developed in python. What are you saying it is a copy of?
I think if you want to exhibit even a gram of integrity you should re-open this issue so that people who are hit by it can find that there is a way to get their fans back under control.
new system - win10, i7-11700kf, gigabyte z590 gaming x latest BIOS F7c, noctua nh-u12a chromax black, lian-li lancool mesh 2, 2x noctua nf-p14s redux 1200rpm, 2x noctua nf-p12s redux 1700rpm.
Initially I set the fan curves in the BIOS and it worked fine, after discovering and installing fancontrol all fans will spin at max and ramp up and down every second or so when fancontrol is not running (while booting, in BIOS). I have tried reconfiguring fan speeds in the BIOS but it doesn't behave as expected. Fan settings I have tried in the bios:
Everything works normally once I have booted and fancontrol starts controlling fans, but I'd like to have the fans behave a bit more normally when not under fancontrol.
I would also like to understand what fancontrol is doing to the bios settings when I set it up. Why does the bios settings seem to make the fans behave in reverse of what would be expected?