Problem with ITE IT8792E/IT8795E - values are ignored #251
Comments
|
Same Problem for me as well. Release: 1.0.201
|
|
Please check the latest build, this might be fixed now. |
|
Still not fixed for me. |
|
Problem still exists with the latest version. |
|
Does latest OHM work for you? |
|
I have the same problem with latest OHM. |
|
Any updates on this? |
|
We'd need a developer with this hardware first. |
|
is adding support for this chip easy? can one learn how to do it? |
|
If you know how to code, have a motherboard with it to test, and preferably get the documentation for this chip, then yes. |
|
@PhyxionNL (sorry for the ping didnt know who else to ask)
Ramble |
|
@NineBallAYAYA I don't think so. The best source of documentation is the Linux driver at the moment, https://github.com/torvalds/linux/blob/master/drivers/hwmon/it87.c |
|
@PhyxionNL Thanks a lot, was quite worried i would slip up and brick something. Ill give it a shot tommorow and hopefully i can get something working somewhat soon. |
|
It's probably a small thing that needs changing, like a different registry or that it uses ext reg. You can experiment a bit with the possibilities here and base it off the Linux driver where possible (you can compare the features with other IT sensors). |
|
has anyone made any progress on the IT8792E chip? I just cloned the enlistment and added the controls in but need to figure out the correct reg values. I'm on an Auros Master X570. I'm able to control on fans on the IT8688E chip. |
|
I took a look at the it87.c file above and the code in the lib. They seem to be in sync with each other (other than the linux file using 6 byte arrays which I added to the lib. No luck making those changes either. I wonder if fan control 5 by gigabytes has the values and could be decompiled. |
Not much on my attempts.. Most ive figured out is that someone partially implemented the codepath for it under the name "IT879XE (DEVID = 0x8733)" this explains why it can read values. I poked around a lot and most ive figured is its probably just writing wrong reg values / addresses. So I basically came to the same conclusion as you but I havent figured out a solution yet so keep me posted if you figure something out. |
can you use fancontrol5 to control those fans while checking which reg values change? |
|
This was my original plan but as jeff said, i dont think it would be possible unless you manged to get between fancontrol and the chip and i dont know how you would do that on windows. However it might be possible to modify the linux driver so it logs the values sent to the chip and that should* be fairly easy. As a last resort just opening control 5 in cutter/ida/ghidra might work but will probably take forever to find anything of use. |
|
I took a second look at the issue on my Gigabyte X570 this morning. The register values are correctly addressing the fan speeds. The problem is that the BIOS is maintaining control over the fans. By spinning in a loop on the call to SetControl I could see the fans actually spinning up and down but only for the length of time I was constantly setting the value. I wonder if there is a secondary command that needs to get sent to let the BIOS know the fan is controlled in software. |
Now that i know someone else is also having the same strange issues, I can also confirm this on my x570 pro. On my AIO pump, bios is set to 50%. When I set the speed to 0%, the pump dips for a second then back to 50%. 1350rpm steady, then dips to 1200 rpm then back to 1350rpm, very audible for my pump. I guess, whatever the code is doing to the IT8688E (other chip on MB that respond correctly to fan control) is not working for IT8792E |
|
Probably the values written in SetControl are incorrect, one of them should specify manual control. It might be related to the old_peci value in it87 driver. |
|
Adding some info to this: Found a pdf with the IT8792E addresses here: https://github.com/richard378/it87-eol I've also found this commit which indicates that there is some kind of problem leaving the configuration mode of the chip. Not sure how much it's relevant but I'll add it here for future reference: I hope this helps. |
|
Hey there, is this issue still investigated? seems like Shasoosh found the missing piece (as far as i can see with my limited knowledge of driver stuff) Would be nice, cause the shitty stuff from Gigabyte it self causes stuttering when setting fans below 10% (Easyautotune service is pretty trash and i want to abandon it) I found the open source software FanControl which uses ur awesome library and works pretty good except that three of the 8 fans arent controlable because they are adressed by the mentioned chip Same test results as CreeT6 (values getting applied but instantly overriden from bios loop again) I can try to help, not sure how except for testing / sending dumps Got the GIgabyte X470 AORUS ULTRA GAMING (rev. 1.0) Kind regards |
|
Hello and thank you for creating such a cool tool, I have a Z370 Aorus Gaming 7 with the ITE IT8792E chip and recently started using FanControl to replace Gigabyte's SIV. Based on issue 69 in the FanControl Git and this one it seems the issue has been narrowed down to having to set the fan to manual control. For testing, should I update the line below by replacing 0x7F with other values? WriteByte(FAN_PWM_CTRL_REG[index], (byte)(_initialFanPwmControl[index] & 0x7F)); Thanks again Update 10/6/2021: If I use the below instead the fan speed is set to 100%. |
|
Experiencing same issue with a system on gigabyte board. Z270x gaming 7. |
|
@Shasoosh I'll be taking a look at how Gigabyte Intel board is handled in EasyTune but I won't be able to test it since I don't have the hardware to do it. Hail mary code so to say. Glancing at it quickly, it seems to be the ISA bridge using the address found in SMFI LD. @mrehkopf Interesting. Might be a USB through the second chip I assume. |
|
No problem @pwnedgod. Let me know if you want me to test it. |
|
@pwnedgod Interesting find on those chips using SuperIO for disabling the EC custom code. I wonder if it also works on older AMD boards like mine, where we had to do the change via the isa bridge and mmio. I may give it a try. For intel stuff, it may be useful to check out this branch I had started: javs@ac3b569 . I also don't have an Intel board so I stopped there, but some pieces are in. There was a report the way I was getting the address via SMFI was wrong, so that may be a bit off. |
This is a very interesting approach since it might help on X570S AORUS Master as well without having to manipulate the PCI-LPC bridge registers. I wonder if this is also how HWiNFO manages to read out the EC RAM without touching the LPC bridge and LPC mapped MMIO. |
|
@pwnedgod |
@javs @mrehkopf @axel-lebourhis It's also worth pointing out that if your board is a Gigabyte AMD board and SMFI LD is enabled on the IT8792E, then it would still use the ISA bridge implementation, same with EasyTune. The ECIO thing might be an AM5 Gigabyte board thing, so I am not sure whether it will work on the older boards. If you guys are interested in checking out the EasyTuneService's dll, the code is located in the assembly |
|
Okay, so I changed the SMFI address processing to match the EasyTune's one. When comparing the output of the current host address manipulation against EasyTune's function (copy paste mock) with input address:[0...65535] and addressHi:[0...255], it has some differences. Since I can't test this, could someone try this on their system? Again, this does not fix Intel just yet |
|
Good evening, I've already taken part in this discussion and I must admit that I was beginning to lose hope.
|
|
@antt0n Hello, have you tried restarting the system before running my build? This usually happens if you have run a prior version, FanControl, or any LibreHardwareMonitor based program without restarting. Please also make sure to disable start up with windows for those two programs. Also, if the problem persists even after you restarted without any traces of previous version, please provide me the report by File -> Save Report.... |
|
Re, |
|
@antt0n Thanks for the report. Your report shows that the chip was reporting 0x8883, which means something must have caused it to enter that state. I am not sure what thing would have caused this other than LHM or FanControl at the moment. I'll take a look on how to fix the chip's state through LHM so it can be properly identified. |
|
I think I've managed to detect the software that's causing the problem. |
|
@antt0n Amazing. I'm glad that it worked out for you and found the software. I tried SignalRGB myself and it messed up the IT8792E state. I can't determine what it does exactly, but it might have the incorrect method. Just extra info: Edit: Adjusted based on @antt0n's info |
Here are the details of how my fans are connected to the MB. SYS_FAN8_PUMP - CPU Pump (WC) - be quiet! silent loop 2 360mm I've reported the problem to the SignalRGB teams, and they'll be working on a fix in the future. It has to do with the fact that they do an ITE Enter. |
|
@pwnedgod SignalRGB App dev here. We use the same ITE Enter function that Libre does at the moment. So any issues main branch Libre has we will too. I'll keep a close eye on this and make sure all of our stuff is compatible in the future as I'm in the middle of adding ITE support. If there's anything we can help with from our end don't hesitate to ping me. |
|
@pwnedgod I tried your last build on my Aorus X570 Ultra. I also had SignalRGB and FanControl running, so I disabled both and reboot. Controls are showing up, but still unable to set a value. |
|
@axel-lebourhis Could you run this build? I haven't made any logical changes to the controls from the latest one, but I added a field for the report to identify what kind of method it uses for the Gigabyte EC. Could you upload a report from this build? Branch: https://github.com/pwnedgod/LibreHardwareMonitor/tree/smfi-address-fix |
|
Found this on a lark and just wanted to add that the latest build here works on my Gigabyte X570 Aorus Pro WiFi. Thanks for all the work! |
|
@digital-pet Thanks for testing. I just want to confirm. Are you able to control the fans on the second chip? (IT87xx) |
Yes, I now have full control over the fans on the second chip with the build you posted. |
|
@digital-pet Very nice. Could you post the report of LibreHardwareMonitor (File -> Save Report)? I want to cross check with others' reports. |
|
I managed to make LHM display the last two fans. It involves reading the EC around Also, I increased the timeout of disabling the Gigabyte EC to 400ms. I suspect some machines fail to set because of insufficient timeout. This is just a big assumption though. Please test as needed and attach your report. https://github.com/pwnedgod/LibreHardwareMonitor/tree/extra-controls
|
|
I managed to update the control value for the extra controls, but it seems that we might need more than just writing a byte as the value for control. The value is reflected into LHM but not the actual fans. Branch: https://github.com/pwnedgod/LibreHardwareMonitor/tree/extra-controls |
LibreHardwareMonitor.Report.txt
LibreHardwareMonitor.Report.txt No control with those 2 builds on my board. |
|
Apparently, disabling the controller also disables monitoring for the IT57xx chip (the RPM values freeze, possibly temperatures as well), which is very unfortunate. Unless there is a direct way to control the IT57xx, then it would be kind of impossible to control without the Gigabyte EC. |
Unfortunate, but not surprising. The idea of disabling their custom controller code was because, in our motherboards, the ITE chip is still drivable via SuperIO like any other one. By disabling their custom code, it would stop overriding the registers we set via SuperIO and everyone is happy. We use the plain ITE registers for that model family same as every other motherboard. In your case, since that doesn't appear to be an option any more, what you may want to consider doing is writing a driver for their custom EC instead. I did some research earlier and this should be entirely possible. In the EC scratch RAM area where we turn off their custom code, there are other offsets that allow you to read and control the fans using Gigabyte's scheme (which is what the Easy Tune service / SIV uses). These may vary in your newer board, but the idea should be the same. Understandably this is much more effort as you cant reuse much of what we have for SuperIO rpm and thermal, but achievable. |
That is true. However, reading and writing into the Gigabyte EC using Gigabyte's control scheme would be slightly overkill, because it only takes in "Complete" fan control schemes with all the curve settings, etc., if we were to abstract the Gigabyte controls behind the I also confirmed that the IT5701 is indeed a USB device. You can check this yourself on devmgmt.msc under "Human Interface Devices" as 2 "HID-compliant vendor-defined device". Check under the tab "Details" and select "Device instance path" and it should be something like "HID\VID_048D&PID_5702&COL01..." and "HID\VID_048D&PID_5702&COL02...". Regarding on how to connect to it, I don't know yet, but OpenRGB might have code pointers that might give a hint on how write data into it, hopefully not just limited to its RGB control capability. |
My version of SIV has an alternative mode called "RPM Fixed Mode" that looks more like what LibreHardwareMonitor would need, this way you avoid doing all the curve stuff. It internally does like a 1 point curve with slope 0 if I remember correctly.
Interesting, I have that too it seems, never noticed. There are some google hits for a few MBs on the Gigabyte website for a tool called "GIGABYTE IT5701 RGB lighting controller firmware upgrade package". |
|
In
|
and others
Release: 1.0.191
Motherboard: Gigabyte Z390 Aorus Ultra
Problem with IT8792E/8795E:
Any value set with fan control seems to be ignored and does not affect the fan speed.
I see that a similar issue was addressed in 235 but unfortunately I'm still experiencing it.
The text was updated successfully, but these errors were encountered: