Fans PWM control not working on Gigabyte B560M DS3H V2 (ITE8689) #11
Comments
|
@PsychoRS thanks for the comments. I will see what I can find out, or if there is a way to actually adjust the fan speeds. |
OK, I only just found this thread, I thought I was doing something wrong, as my Gigabyte AORUS B560I motherboard also appears not to allow fan control. I too am running UnRAID, using the IT87 driver package from ich77 As part of my troubleshooting, I installed a third fan, and set the BIOS fan speed control to 100%. When using the dynamix autofan plugin, and trying to detect the fan, it does slow the fan down, but only the first attempt. same with setting the fan speed, it will work on the first attempt after a reboot. Any further attempts to change the fan speed do not result in any change, the fan speed will be stuck at whatever you set it to that first time. Bizarre. And the way the detecting of the fan works that first time, the fan slowly ramps down from 100% (I can watch and hear it), then there is just no further control until you reboot the whole system. EDIT: I am not using and ignore conflict (it87.ignore_resource_conflict=1), should I be? |
|
@eatoff8 thanks for the comment, that adds a bit more information, i.e. that it works once. Also, no, there is no need to set it87.ignore_resource_conflicts=1 for this board, if it is a B560I AORUS PRO AX, as it is detected automatically. |
Exact same behaviour as mine, fans slow down to stop the first time I click detect (or fire pwmconfig from the CLI) a then onwards fans doesn't respond anymore |
|
@frankcrawford Thanks for all the help with the driver package! Bizarre that it works the first time, and then never again until after a reboot. Is there any kind of diagnostic or logs i can provide that could give you more clues? @PsychoRS EXACT same behaviour. I thought i was going crazy that it worked and then it didnt. |
|
Unfortunately, no, there are no additional logs than what appears in I will look at adding a few additional debug messages. |
|
I have the same motherboard.
Hope you've already solved the issue |
|
@demetera Thanks for that. It matches what I thought is the issue, i.e. we are using the wrong registers for the PWM configuration, but I hadn't had a chance to track them down. I'll test out your fix and, if there are now issues, will update the registers for the ITE8689 chipset. Two questions, firstly, did you check the other sensor outputs, i.e. temp, power, etc, to ensure they are unchanged? Secondly, how did you pick this ID, was it just testing other valid chipsets, or was there something abut it that look appropriate? |
|
Thanks for your comment @frankcrawford
Cheers! |
|
@demetera thanks for the update. A quick test does seem to show that pwmconfig makes changes to the fan speed so it looks promising. |
|
Nevermind, just changed id from 0x8689 to 0x8628.. PS: No, sorry, it's not working as expected, Fans slow down on pwnconfig test but never spin up again. As you can see, the fan slow downs a bit (from 1400RPM to around 800RPM) when /sys/class/hwmon5/pwm1_enable is set to 1 (manual) by pwmconfig, but pwm control is non-existent. I can echo 225, 220, 120, 0... to /sys/class/hwmon5/pwm1 and the fan doesn't react, just have to set pwm1_enable to 2 (auto) again for the fan autoadjust. |
I was so hopeful. @frankcrawford is there a list of other chipset id's we could try? If there arent too many it could just be a process of elimination |
|
@eatoff8 that is also what I saw, which is why I was interested in getting it tested further. I also don't think it is as simple as different chipsets to try as they are all very similar. The issue may also be how pwmconfig expects to modify the configuration vs what is available. The current change is that it allows the user to "turn the fan off", but in reality, that isn't doing this, it is just dropping the speed significantly, not actually stopping it, which may not be the same at all. |
|
Yes, the fan never stops in my case. It just moves between 1200-750 rpm in a very narrow pwm_input range. And its an Arctic P12 PWM with a range of 0-1800rpm. I will be happy to test anything you need. |
|
Hi guys, @frankcrawford ite8689 didn't work for me. Only 0x8628. If i have to test with other parameters, please let me know, which ones to apply. @PsychoRS My goal was to minimise the fan noise eventually. I have a profile in BIOS - to start the fan to cool, when temp exceeds 70 deg. When temperature drops down below the threshold - fan is still taking his journey to rotate (i guess it's motherboard feature) |
So controlling the fan speed does work? you just cant get it to stop? Or there is no control, it just one time drops to 750rpm until you restart? My use case is for cooling my hard drives in UnRAID. I want to set a minimum speed (say 800rpm) and then depending on the temp of the HDDs ramp the speed up. I dont want to actually stop the fan, just ramp it up and down (not stop). |
No, the fan isn't controllable. It ramps down to around 800rpm but never goes back to 1300-1500 (high speed). I'm also wanting to use it as any array fan for unRAID. |
|
I'm pretty sure it should be controllable but for some reason it either goes to automatic or full, not allowing manual mode, which pmwconfig expects. However, in reality for both jobs you mention automatic may do, as it allows you to set cutoff points where the fan spins up at certain rates, until it reaches a max and then stays there. It is the same as what pmwconfig does in software, but just done in firmware. I'll put together some notes about what needs to be set for it to work. |
|
@demetera the current driver for the it8689 chipset doesn't seem to do PWM controls properly, and the setting for 0x8628 just happens to trip something that does make some variation to the fan speed but not in any real controlled manner. The fact it does something indicates that there is some ability there, and I'm trying to figure out what is the trigger, and hence update the driver to do it properly. BTW, the 0x8628 value is almost exactly the same as it is believed to be an earlier model of the chipset, just with an auto-on/off feature enabled. |
Yes Frank, but what I want to achieve is to set the fan speed according to HDD's temperature, something that auto control from the firmware/BIOS doesn't allow to do (you just can choose CPU Temp or MB Temp). For that reason I'm trying to get manual control with pwmconfig, so I can choose my HDD cage as source for referenced temp to control the fan speed (something that unRAID can do via a plugin, but at first you need to have manual PWM control of the fan). Thanks for your work. |
|
I have encountered the same problem with the Gigabyte Z690M AORUS ELITE motherboard and the IT8689 chipset. However, I've finally figured out how to make it work. The main idea is to disable the motherboard's control of HDD fans. Unfortunately, I couldn't find an option to completely disable the control of specific fans in the BIOS settings. Instead, I set a very high CPU temperature threshold(like 80-90C), causing the HDD fans to spin up. The key is to prevent the motherboard from initiating the HDD fans so that I can control them from Unraid. |
The method I tried was to enable the fan at the full speed setting. you are saying to disable the fan completely? have it switched off? Might be something i can try over the next week. |
Exactly! I wasn't successful in controlling the HDD fans from Unraid until I made sure that the motherboard never starts these fans. |
|
That is very interesting. Unfortunately without some documentation from ITE it is hard to see how to program this. I'll see what I can find, but keep up the search. |
So, I just tried this, and yes, it works. I ran through PWMCONFIG multiple times and the fan ramped up and down every time (not just first time). I then set the autofan control based on HDD temps, and it adjusts the fan speed, stops the fan etc as required. This is how I set up the fan curve and other settings to get it working
Setting it to full speed did not work at all, that was how i was trying it previously. |
|
Guys, thanks for this. I wonder if I can program it to set the curve like that before doing the rest, as there are other registers that seem to be related to how this curve is done. |
Hooray! After BIOS upgrade to F9 I tried this layout (Gigabyte B560M DS3H V2 with ITE 8689) |
|
For everyone following this thread on the failure to set the fan speed, I've come across the reason for the problem, and possible coding to fix it in LibreHardwareMonitor/LibreHardwareMonitor#251 However, as the code is fairly complex, it will be a while before I can get to looking at adding it, so don't expect a quick fix. |
Same here, Aorus X570 Master. I can set fans that are under it8688-isa-0a40 but I cannot set other fans (even rpm values are wrong) for it8792-isa-0a60. LibreHardwareMonitor/LibreHardwareMonitor#251 (comment) |
|
Hi guys, I also have problems with pwm control on Gigabyte B760M GAMING X DDR4 with ITE8689. This board has four 4-pin connectors, one for the CPU and the others for sys_fans. If I connect two PWM fans, sys_fan_1 (pwm2) and sys_fan_2 (pwm3), the first one stops spinning after a while when the fans are controlled by fancontrol. It twitches occasionally. I compared all pwm related hwmon files and found out that the pwn2_freq file content changes after some time from 23437 to 187500. Changing it back to 23437 makes the fan spinning again, but something overrides it after a while again. So far, I think that only sys_fan_1 (pwm2) is affected. I guess that it's not fan related because after swichting the fans, the same behavior is shown on the other fan. Are there already any ideas how it could be fixed permanently? The fancontrol config looks like this: INTERVAL=10
DEVPATH=hwmon3=devices/platform/it87.2624
DEVNAME=hwmon3=it8689
FCTEMPS=hwmon3/pwm2=hwmon3/temp1_input hwmon3/pwm3=hwmon3/temp1_input
FCFANS=hwmon3/pwm2=hwmon3/fan2_input hwmon3/pwm3=hwmon3/fan3_input
MINTEMP=hwmon3/pwm2=20 hwmon3/pwm3=20
MAXTEMP=hwmon3/pwm2=60 hwmon3/pwm3=60
MINSTART=hwmon3/pwm2=150 hwmon3/pwm3=150
MINSTOP=hwmon3/pwm2=150 hwmon3/pwm3=150
MINPWM=hwmon3/pwm2=150 hwmon3/pwm3=150
MAXPWM=hwmon3/pwm2=255 hwmon3/pwm3=255 |
frankcrawford
added
bug
|
+1 Removing the fan curve in bios does seem to make the fans controllable, not a solution really tho. Bios also seems to freak out doing that. Reducing 1 header to zero completely messes up the others. |
|
Same for "Gigabyte H610M H DDR4" // IT8689E-BXA. pwmconfig can't control fan speeds, only slow down it a bit as reported before. I've tested that lax grub option not required, but booth force_id and ignore resource conflict are (without any of it 'sensors' failed to report any hardware info). Not sure if it is related. But when I set 'PWM' control in Gigabyte BIOS "Smart Fan", fan start to work at full speed, and seems fan control get broken. But when I set it to 'Voltage' it works as expected. |
|
@axet the current code should detect an IT8689E, but I suspect an IT8689-BXA is actually a different chip. Can you run On the other side of the PWM control not working, it is a list of things to follow up, but currently not something I have had a chance to get into. |
|
|
@axet I was thinking about this last night and am wondering which it87 module you have loaded? The one from this repo, or the one from the kernel mainline? Can you do |
|
That is how I do it: EDIT: updating to the recent release, let use no force option, but ignore_resource_conflict still required. |
|
@axet ah, that is a bit better then. Yes, to not need the For me to add it, please run |
|
"Gigabyte Technology Co., Ltd." // "H610M H DDR4" |
|
Given it is a Micro ATX, I assume it only has a single ITE chip on the motherboard? Is that correct? |
|
When I looked at board I only seen one. But I didn't expect two EC on a single board ever. |
|
Yeah. The bigger boards with many, many fans, etc, can have 2 chips. But for your board I wouldn't expect so. If you pull the latest git update, that I've only just pushed, you shouldn't need to set |
|
Thanks. Do you have datasheet for IT8689? I've seen it can be requrested from ITE directly using support email. It should have all registers / memory address information related to fan and voltages. |
|
@axet no I don't have the datasheet, I've tried to request them many times and they ignore me. If you do get it, then it will be very appreciated. If you can setup a long term contact it would be even better. |
|
@axet
I don't know why this hasn't shown up in the github issue yet, but to
explain why it is as complex as it is, is covered in the actual commit
for it to the mainline kernel, i.e.
On various Gigabyte boards, incorrectly entering configuration mode
causes the second Super-IO chip to generate LPC bus access errors.
This was preivously fixed by ensuring that the second chip receives the
code to enter configuration mode before the first chip.
On discussion with people who have access to the specification
documents
it was noted that this is wrong, and you should not enter or leave
configuration mode for the second chip, as it is enable during
initialisation and should not be changed.
In particular, this was found to be the case on the Gigabyte X670E
Aorus
Master board, where it was reporting a totally wrong chip ID (0x8883)
using the previous method. This was corrected by not entering
configuration mode, and this has been found to still work with older
boards.
As such the main process is:
1) Lock the memory, but does not perform a SIO entry (previously it
would have performed an SIO entry).
2) Attempt to read the chipID. This should be safe no matter which
chip we have.
3) If step (2) fails, then perform SIO entry and retry chipID read.
For
older chips and on failure it acts similarly to prior to this patch.
4) Set the sio_data->type, similar to previously.
5) If we have not performed an SIO entry, and this is not a chip type
with the NOCONF feature, then it will perform an SIO entry at this
point.
6) Proceed with setup as prior to this patch.
7) Any following access to the SIO registers will invoke the SIO entry
and SIO exit steps unless it is a chip with the NOCONF feature set.
This was set up in the previous patches in this patchset.
8) Update to the exit based on if it had performed a SIO entry or not.
I didn't add into there, but we check a chip exists before we use the
force_id parameter, to avoid doing anything to non-existent memory.
Regards
Frank
On Sun, 2024-08-18 at 22:43 -0700, axet wrote:
@frankcrawford [1] I'm working on it. In your code you do check chip-
id using the following:
port 0x2e, and data 0x20 to get chip it
And if it fails you check force_id param is set. Why are you doing
it? As I know to get chip id you need to send the sequince:
b'\x87\x01\x55\x55'
And you will get correct id from port 0x2e and 0x2f using data offset
of 0x20 and 0x21. I guess that is the correct way of reading
chip_type id.
I'm asking this, because I have interesting idea how to recover ITE
chip information related to fan control and temperatures. But I need
few details.
—
Reply to this email directly, view it on GitHub [2], or unsubscribe
[3].
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
My comment didn't show up because I wan't to rewrite it and make question more clean. Since we have no docs (yet, or ever) I suggest we could extract some information from EFI bios binaries. Turns out EFI is modular which can be parsed and extracted module by module. Here is a tool https://github.com/LongSoft/UEFITool which can do the job. Using this tool and Gigabyte firmware for my motherboard (H610 with IT8689 EC) file I able to find some ITE related modules I assume works with the chip to extract system information like voltage, fan, temp. And to my surprise this mother (which having IT8689E chip on board) but having no references in the firmware file for IT8689. But at the same time I found two different ITE chips: IT8688 and IT8728. What is that? Could it be that those chips are 100% compatible with IT8689? I do not know yet. I've extracted related blobs and turns out those blobs are PE compatible blobs. Basically Microsoft Windows exectuables. A bit of topic information: even worse I found NTFS support in my bios firmware but no EXT4 or LUKS support. Extracted PE files can be analyzed using IDAPRO which I did and found out a few already known commands like "87 01 55 55" for chip initialization. Not much yet. My initial question was how to it87 driver controls fans speeds so I could find related IO ports operations in extracted blobs using disassembler. And another solution could be based on fact that motherboard firmware only contains code for IT8728 and it8688 could we reuse what we know from those chips datasheets? Since we have no it8689 docs... |
|
@axet that is very interesting, and something I haven't tried previously. Certainly, in my code, the it8689 is treated essentially the same as an it8688, so they almost certainly have the same configuration. On the other hand the it8728 does look substantially different, at least for the hwmon part. If you look at the code within it87.c then you will see this definition: where these arrays are given earlier. However, with datasheets, I have never been able to get any for ITE86XX chipsets, only for ITE87XX, and then only for old ones. Gigabyte and ITE are really hard to get a decent response from. |
|
P.S. I am lead to believe that such datasheets exist, because another developer on Windows systems, where they can actually pay some money and enter NDAs has access to some of them. Also, if we are going further with this, it would be best to open a new issue, rather than continuing with this particular one. |
Hi Frank,
I'm using your driver, packaged by ich77 for unRAID.
Board is a Gigabyte B560M DS3H, with an ITE8689. With your driver, I can see the fan's RPM (sensor-detect detects the 8689), but I'm facing the problem that the fans are not responding to any pwm changes. pwmconfig fires up, detect the fans, but when it tries to adjust the rpm while probbing, nothing happens.
If fact, fan speeds doesn't vary when I modify the contents of pwm1/2/3/4 via an echo 0.
It looks that there is no correlation between the data of pwmX inputs and the speed of the fans (as you can see, in this pwmconfig launch, all fans are set at full speed pwm, 255, but they aren't at their real full speed, looks like they are only controlled by BIOS and doesn't react to software changes.
unRAID 6.12.1
Thanks in advance.
The text was updated successfully, but these errors were encountered: