it87
it87 copied to clipboard
Help to get the sensors working for a Gigabyte X670E Aorus Master (AM 5 Board with Ryzen 9)
Hello Frank,
over the last weeks since I have a new PC built I did quite a lot of research how to get the temperature sensors to work. Just with the stock lm-sensors, nothing is really working.
I also tried to get to know how I could build a driver, but actually I am a little lost what I need to do.
Maybe you can help, as I would like to provide also to others a working solution. As we are kinda blind when it's about CPU temperatures with this new boards.
Some Questions:
- How can I determine which precise chips are shipped with the board? With sensors-detect I found this:
Trying family `ITE'... Yes
Found unknown chip with ID 0x8689
Probing for Super-I/O at 0x4e/0x4f
Trying family `ITE'... Yes
Found unknown chip with ID 0x8883
(logical device 4 has address 0x290, could be sensors)
-
Where can I find the the correct drivers for these chips?
-
How do I build the drivers and make them available as you did?
Thanks a lot for the good work! :)
regards
FB
You need to build the it87 module using the code in this repo. See: https://aur.archlinux.org/packages/it87-dkms-git
@f45tb00t sorry about my slow response, I've been tied up with other things.
Firstly, sensor-detect
only correctly handles sensors in the standard kernel module, not the additional ones in this module.
As for how to build it. For a simple test you can download this repo and just run "make" and then "sudo make install", which will overwrite the existing kernel module. After that, you may need to reboot for the new module to take effect.
However, for ongoing installation, as you upgrade your kernel, you probably want to use the dkms
package, and hence you can follow the instructions above. You do need the dkms
package installed, and that depends on your specific OS.
Alternatively, if you have dkms
installed, you can also just run the script dkms-install.sh
found in this repo, but that may not always work.
Anyway, see how this goes and let me know if it works for you
Hey @frankcrawford i have the exact same board and have been using your kernel module for a while now. I'd be up to provide required data and testing if you need something. The mainboard has 8 fans, but the "compatibilty" mode your module uses shows only 5 of them.
This is the current sensors
output on linux kernel 6.5.0-5-amd64
(debian):
it8689-isa-0a40
Adapter: ISA adapter
in0: 756.00 mV (min = +0.00 V, max = +3.06 V)
in1: 2.00 V (min = +0.00 V, max = +3.06 V)
in2: 2.00 V (min = +0.00 V, max = +3.06 V)
in3: 2.03 V (min = +0.00 V, max = +3.06 V)
in4: 1.14 V (min = +0.00 V, max = +3.06 V)
in5: 1.14 V (min = +0.00 V, max = +3.06 V)
in6: 1.99 V (min = +0.00 V, max = +3.06 V)
3VSB: 3.29 V (min = +0.00 V, max = +6.12 V)
Vbat: 3.24 V
fan1: 0 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
temp1: +41.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +59.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp3: +57.0°C (low = +127.0°C, high = +127.0°C) sensor = AMD AMDSI
temp4: +49.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp5: +48.0°C (low = +0.0°C, high = -125.0°C) sensor = thermistor
temp6: -55.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
intrusion0: ALARM
@programminghoch10 okay, I can see the issue, I think, the Gigabyte X670E Aorus Master looks to have 2 chips, with the it8689 only providing 5 fans, and the other would provide the other details.
However, we need to see what the other chip is, so are you able to provide additional details on what chips are in the system?
@programminghoch10 looking at some other online documentation that board also has an IT8792E (hw ID 0x8733) chip. If you run sensor-detect does it show anything else? Secondly does anything else appear in the boot log for the it87 module?
@frankcrawford
sensors-detect
:
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... Yes
Found unknown chip with ID 0x8689
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... Yes
Found unknown chip with ID 0x8883
(logical device 4 has address 0x290, could be sensors)
Yes it seems there are two ITE chips connected.
I don't exactly know what you mean with "boot log", I assume this:
$ dmesg | grep it87
[ 9.294881] it87: loading out-of-tree module taints kernel.
[ 9.294885] it87: module verification failed: signature and/or required key missing - tainting kernel
[ 9.295680] it87: it87 driver version v1.0-137-g1663f97.20240207
[ 9.295839] it87: Found IT8689E chip at 0xa40, revision 1
[ 9.295966] it87: Beeping is supported
@programminghoch10 how confident are you with git, and with making and installing modules into the kernel?
I am thinking of trying a few things in a separate git branch but would need you to compile it and test it, as I don't have that board.
@frankcrawford absolutely no problem. Bring it on! 👍
@programminghoch10 when you have a chance can you try the dev branch it87922e in the github repo.
First checkout the test branch ("git checkout it87922e") and then you will need to compile it ("make"), unload the current one ("modprobe -r it87") and load up the local one ("modprobe hwmon_vid ; insmod ./it87.ko").
If I have it correct, it should detect the second chip as an IT87922E (TBC). Then secondly, see if the values look to be correct.
@frankcrawford
sensors
:
it8689-isa-0a40
Adapter: ISA adapter
in0: 744.00 mV (min = +0.00 V, max = +3.06 V)
in1: 2.00 V (min = +0.00 V, max = +3.06 V)
in2: 2.00 V (min = +0.00 V, max = +3.06 V)
in3: 2.03 V (min = +0.00 V, max = +3.06 V)
in4: 1.14 V (min = +0.00 V, max = +3.06 V)
in5: 1.14 V (min = +0.00 V, max = +3.06 V)
in6: 1.99 V (min = +0.00 V, max = +3.06 V)
3VSB: 3.29 V (min = +0.00 V, max = +6.12 V)
Vbat: 3.24 V
fan1: 167 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
temp1: +41.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +61.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp3: +70.0°C (low = +127.0°C, high = +127.0°C) sensor = AMD AMDSI
temp4: +51.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp5: +51.0°C (low = +0.0°C, high = -125.0°C) sensor = thermistor
temp6: -55.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
intrusion0: ALARM
still shows only one ITE sensor device
dmesg | grep it87
:
[ 7.407978] it87: loading out-of-tree module taints kernel.
[ 7.407982] it87: module verification failed: signature and/or required key missing - tainting kernel
[ 7.408683] it87: it87 driver version v1.0-137-g1663f97.20240207
[ 7.408850] it87: Found IT8689E chip at 0xa40, revision 1
[ 7.408977] it87: Beeping is supported
[ 9285.619736] it87: it87 driver version v1.0-142-g58fda1f.20240210
[ 9285.619957] it87: Found IT8689E chip at 0xa40, revision 1
[ 9285.620097] it87: Beeping is supported
[ 9285.624185] it87: Device (chip IT87922E (TBC) ioreg 0x4e) not activated, skipping
btw thanks for reminding me that kernel modules can be loaded dynamically, I do know me some linux but I totally forgot about that and thought I would have to reboot after dkms
installation :eyes:
@programminghoch10 well the output from dmesg shows it did detect the other chip, but didn't activate it.
It may be an issue that the second chip may need to be configured first, which is a known problem. To correct it, you may need to reboot your system, and ensure that the new module is the one loaded, not the older one.
@frankcrawford
I've made a dkms
install and rebooted.
The sensors
is the same, still only one device.
dmesg
seems to be the same too:
[ 5.848180] it87: loading out-of-tree module taints kernel.
[ 5.848184] it87: module verification failed: signature and/or required key missing - tainting kernel
[ 5.848698] it87: it87 driver version v1.0-142-g58fda1f.20240211
[ 5.848902] it87: Found IT8689E chip at 0xa40, revision 1
[ 5.849029] it87: Beeping is supported
[ 5.853051] it87: Device (chip IT87922E (TBC) ioreg 0x4e) not activated, skipping
@programminghoch10 okay, I'll have to see what I can find out about why it isn't activating.
Thanks.
@programminghoch10 I've just pushed a new version, although all it does is add some more messaging, so I can see what is going on.
Also, can you send the output from /sys/class/dmi/id/board_name and /sys/class/dmi/id/board_vendor
Thanks.
@frankcrawford i pulled, make
d and inserted directly (no dkms
)
[14678.472253] it87: it87 driver version v1.0-143-gc51843b.20240213
[14678.472338] it87: Entering config for second chip
[14678.472521] it87: Found IT8689E chip at 0xa40, revision 1
[14678.472656] it87: Beeping is supported
[14678.477131] it87: Device (chip IT87922E (TBC) ioreg 0x4e) not activated, skipping
$ cat /sys/class/dmi/id/board_{name,vendor}
X670E AORUS MASTER
Gigabyte Technology Co., Ltd.
Hmm, the values are coming back right, but not activating properly, so I need to look into further.
@programminghoch10 I've done a hack to get past the activation issue. See how it works, but also be aware that this is slighlty dodgy, so be prepared to roll it back.
@frankcrawford
[ 1895.002060] it87: it87 driver version v1.0-144-gc3fd522.20240213
[ 1895.002092] it87: Entering config for second chip
[ 1895.002269] it87: Found IT8689E chip at 0xa40, revision 1
[ 1895.002397] it87: Beeping is supported
[ 1895.006482] it87: Found IT87922E (TBC) chip at 0x290, revision 1
[ 1895.006568] it87: Beeping is supported
sensors
output is still the same, only one device
Hi guys,
sorry for my late reply... Life... you know...
It's awesome that you work on this. I'll test as well. Meanwhile I tested also other alternatives. What works for me is another project. CoreFreq.
@programminghoch10 Maybe some things to share with you about the board I found out
- Be aware that when you upgrade to 4X RAM, the EXPO profiles won't work anymore. I've contacted the GigaByte Support and they told me that when you use full rambanks, that the profiles do not work anymore, as the specification of the CPU does not allow that. I was not aware about that and my DDR5 6k chips cannot be used at full speed. I've now 128GB RAM with a timing of 3600 instead 6000.
- I've unfortunately issues with the 5.1 sound over HDMI (iGPU). Tried also bleeding edge Ubuntu for instance, but only 2.0 Sound works.
Beside that I am really happy with the setup. With the Ryzen 7900 (non x version because of 24/7 usage and the power consumption) the pc is a monster :D Also the 6 SATA ports are reliable so far. Running them with a RAID 6 with 6 disks. For the OS and VMs I use two nvme disks
@programminghoch10 Another attempt, based on some comments I've recently been given.
@f45tb00t that is an interesting item about 4X RAM causing a problem with EXPO profiles. I think I've seen that previously on other boards.
@f45tb00t that is an interesting item about 4X RAM causing a problem with EXPO profiles. I think I've seen that previously on other boards.
It seems this is a common problem. Unfortunately.
Max Memory Speed
2x1R DDR5-5200
2x2R DDR5-5200
4x1R DDR5-3600
4x2R DDR5-3600
Ref: https://www.amd.com/de/product/12746
To be honest I was not aware about that. I think that would have changed my "buying-mind" a little. Because why should I buy then faster RAM for much more money, if they just do not run as expected. I did not try to get the maximum out by manually tweaking, as I need a reliable and stable production system. Furthermore I am not in that tweaking anymore. I don't play games with this pc, so therefore I don't care about 0,00001% more speed. But surely the EXPO was an interesting thing. My last PC was like 10+++ years old, still running, but got very slow over the last years due to the CPU vulns and the applied fixes. So I decided to create a new one without any compromises this time.
Once I get the temperatures of the Cores and fix the 5.1 sound issues, I'll be totally happy with this setup. Hope it lasts also for 10+++ years. :)
@programminghoch10 so, talking with someone who has some knowledge of the chips involved, it turns out we have this all wrong. What he said is
0x8883 is IT8883FN which is just a plain eSPI to LPC Bridge, more-less transparent on the bus. Behind it usually lies the above chip. 0x8883 should normally not appear on the LPC bus but it can happen if the bug I described below occurs.
The bug he is describing is that the chip locks up if not accessed correctly, which I thought we did, but may not be done correctly.
Anyway, firstly try the version I pushed recently, but expect more changes, to try and get it working properly.
@frankcrawford
[ 147.963350] it87: it87 driver version v1.0-145-gc635724.20240215
[ 147.963387] it87: Entering config for second chip
[ 147.963530] it87: Found IT8689E chip at 0xa40, revision 1
[ 147.963657] it87: Beeping is supported
[ 147.967617] it87: Device (chip IT87922E (TBC) ioreg 0x4e) not activated, skipping
@f45tb00t thanks for sharing your experience with the mainboard
i also got quite the time with it and have a lot to tell,
however im a bit short on time currently, will properly tell you all i found out at a later date
just a quick question though, do you have mainboard of rev 1.0
or rev 1.1
?
@programminghoch10 rev 1.0. As far as I can see there is no 1.1 yet?
@programminghoch10 when you do have some time, let me know and I'll get you to try something else more to see the results.
@f45tb00t there is and i have one after quite some issues with rev 1.0 I'll tell you more at a later date.
@frankcrawford You can keep working on it, i have the 5 minutes to compile and run it on the evening. I just meant that i don't currently have the time to write out the extensive story for @f45tb00t .
@programminghoch10 I am going to keep working on it, but will do a bit of restructuring, which will affect not just you but other chips as well.
However, what I would like you to try, when you have a chance is to: a) blacklist the it87 module (depending on system is something like adding "blacklist it87" into /etc/modprobe.d/blacklist) b) reboot c) run "sudo sensors-detect" to see what is then listed. d) then un-blacklist it87
The reason for this is I want to test if it is the it87 module that is crashing the second chip or something else. If it is the it87 module, you should no longer see the chip ID 0x8887, but a different chip ID (I think).
Oh, rats, I just checked the sensor-detect module and it may be running the bad code as well. Anyway, we will see.
Just changing my request please do the following:
a) blacklist the it87 module (depending on system is something like adding "blacklist it87" into /etc/modprobe.d/blacklist) b) reboot c) run "sudo isadump 0x4e 0x4f 7" (hopefully there won't be lots of "ff" entries) d) run "sudo sensors-detect" to see what is then listed e) then un-blacklist it87
Thanks.