Return to Level1Techs.com

I patched the IT87 (Temperature monitoring) driver, need some help testing it

sensors
#1

I rebased most of Guenter Roeck’s patches for the IT87 kernel module.
My motherboard has an IT8686, so I can test if everything works for that chip. This is my only motherboard, so I need someone that wants to test their boards for issues with the driver.

The driver can be found here:

If you are on debian you can try out the dkms package:

6 Likes

#2

That’s the one popular on Ryzen?

0 Likes

pinned #3

Four days

0 Likes

#4

The original owner deleted the original repo. Yours is likely the only remaining repo left of this code! Clone this wherever you can!

1 Like

#5

Yeah most of the Ryzen motherboards should work with that driver

0 Likes

#6

Any reason for the repo being deleted?

0 Likes

#7

I’ll give it a try this weekend with my x370 taichi

2 Likes

#8

Guy got fed up, quit, and deleted the source code:

0 Likes

#9

The old maintainer didn’t want to port the code to mainline, no idea why though

1 Like

#10

Well, he was fed up with different people bugging him with all the permutations of the controller and it’s configurations, so he quit.

1 Like

#11

Ah, okay. that makes sense.

0 Likes

#12

Sounds pretty good

1 Like

#13

Just a small update. The latest bios for my board (GA AX370 Gaming K7) seems to have broken the driver (I had a backup copy of Roeck’s it87 driver that I was using). So I guess I’m stuck deciding between Ryzen 3000 support or motherboard sensor monitoring.

1 Like

#14

It’s very sad to see that it87 was abandoned.

For those with certain Asus motherboards, asus-wmi-sensors is a fantastic alternative which works much better (temps, voltages, and fan RPMs!) than it87. https://github.com/electrified/asus-wmi-sensors

Unfortunately this isn’t much help if you’re using other brands or motherboards.

1 Like

#15

Found a small fix for the broken it87. I think GB changed something with the ACPI behavior. The following boot parameter resolves the issue:

acpi_enforce_resources=lax

Some say that is a bad idea to use, but I remember running a few older boards with that parameter to fix issues with sensors too. Hopefully GB reverts whatever changes they did for the next bios release.

0 Likes

#16

Hmm - I have that board too and thought I’d installed the 40 or 41 driver with the Ryzen 3000 support and my sensors still work.

I’ll have a look tonight.

I’ve also created an account on Gigabyte’s forums so I could politely ask them to get their engineers to please get the chipset data NDA removed so we can get better Linux support. Especially with Ryzen and ThreadRipper these days they should be selling a ton of these to Linux users and a lack of basic health monitoring because of their choice of vendor for the Super I/O chip they use is just awful.

0 Likes

#17

Maybe it’s just on my particular install? The it87 module kept complaining about the “resource is busy”. Adding the above kernel parameter fixed the issue.

0 Likes

#18

Ah. The Original Maintainer, Gunter Groeck at GitHub suggested (before he tore out the repo):

“dmesg will most likely show you that you have a resource conflict. See acpi_enforce_resources or ignore_resource_conflict module options.”

if:
modprobe it87 ignore_resource_conflict=1

works, then create /etc/modprobe.d/it87 and add:

options it87 ignore_resource_conflict=1

I’ve also had the module get removed after kernel updates on some (but not all) systems, likely due to some magic setting missing and when this happens I have to:

make clean; make; make install (the module)
/sbin/ldconfig
modprobe it87
service lm_sensors restart
service snmpd restart

0 Likes

#19

Those ignore options were suggested to me on another board a while back, but they don’t work for me. And yeah, when you change kernels you have to rebuild the module.

0 Likes

#20

dkms takes care of that. I think you just had to use make dkms_install or something similar, just check in the Makefile.

1 Like