WMI Linux Temperature Driver Being Worked On For Gigabyte Motherboards

[kiffmet]

Keith Myers are you using an out-of-tree it87 driver? modinfo shows that mine doesn't have these options.

[Keith Myers]

Try loading the driver with this module parameter.

sudo modprobe it87 ignore_resource_conflict=1 mmio=1

That should get around the ACPI conflict warnings.

[kiffmet]

On my X570 Aorus Pro using the IT87 driver for reading sensors only yields a bunch of garbage voltage and temperature readings, which isn't surprising considering the driver is unmaintained and every mainboard vendor wires up this chip slightly differently. As for sIO, I am wondering whether a specific driver will even work for me, considering my kernel is already complaining about something being broken in this regard.

[FONT=monospace]ACPI Warning:[/FONT][FONT=monospace][COLOR=#000000] SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegio[/COLOR]n 0x0000000000000B00-0x0000000000000B0F [COLOR=#000000](\GSA1.SMBI) (20201113/utaddress-204)[/COLOR][/FONT]

Well, at least the MMU-groups are properly separated...

[Keith Myers]

I have been enjoying my out-of-band asuswmisensors WMI kernel driver for my ASUS Crosshair VII Hero motherboards for years on their x470 chipsets.

All the expected sensors you get under Windows are visible under Linux. Yay! Happy!

Sadly ASUS dropped the WMI interface in the BIOS for the x570 boards and went with the simplistic Nuvoton 67xx SIO chips which report nothing but garbage under Linux.

[birdie]

Also many or most of the motherboard vendors have broken ACPI tables are not compliant with the ACPI specification.

Which PC motherboard vendor is the best for Linux?

Let me put it this way: any is the best for Windows and at least ASUS, MSI, GigaByte and Asrock suck for Linux.

[birdie]

I think that Windows support is not any better.

You may think whatever you want but you also must admit the facts: HWiNFO64 reports many dozens of sensors while under Linux you can barely see anything and then we have bugs like this one:

https://bugzilla.kernel.org/show_bug.cgi?id=204807

when there's a driver already available but it doesn't work by default and then kernel developers tell you you shouldn't use the driver and instead have no fucking sensors at all because the only driver which was written is not 100% compliant with how the kernel works.

Fuck my life.

So, your "Windows support is not any better" is an absolute load of pristine bullcrap.

Under Windows people enjoy:

• HWiNFO64
• Your motherboard vendor utility
• HWMonitor
• CoreTemp
• OpenHardwareMonitor
• MSI Afterburner
• OCCT

And that's just the utilities which I know and remember. There are others.

[pauledd]

My quite old Gigabyte Z170N-WIFI already had some sensors available in linux for some years:

[FONT=monospace][COLOR=#000000]sensors [/COLOR]
hidpp_battery_0-hid-3-8
Adapter: HID adapter
in0:           3.79 V  

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +30.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +28.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:        +28.0°C  (high = +80.0°C, crit = +100.0°C)
Core 2:        +24.0°C  (high = +80.0°C, crit = +100.0°C)
Core 3:        +25.0°C  (high = +80.0°C, crit = +100.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +119.0°C)
temp2:        +29.8°C  (crit = +119.0°C)

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:            N/A  

it8728-isa-0a40
Adapter: ISA adapter
in0:         852.00 mV (min =  +0.00 V, max =  +3.06 V)
in1:           2.04 V  (min =  +0.00 V, max =  +3.06 V)
in2:           2.02 V  (min =  +0.00 V, max =  +3.06 V)
in3:           2.03 V  (min =  +0.00 V, max =  +3.06 V)
in4:         648.00 mV (min =  +0.00 V, max =  +3.06 V)
in5:           1.07 V  (min =  +0.00 V, max =  +3.06 V)
in6:           1.24 V  (min =  +0.00 V, max =  +3.06 V)
3VSB:          3.38 V  (min =  +0.00 V, max =  +6.12 V)
Vbat:          3.14 V  
fan1:         975 RPM  (min =    0 RPM)
fan2:         545 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
fan4:           0 RPM  (min =    0 RPM)
fan5:           0 RPM  (min =    0 RPM)
temp1:        +31.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +38.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +30.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = Intel PECI
intrusion0:  ALARM[/FONT]

I used kernel module "it87" for that purpose with some special module options:
/etc/modprobe.d/it87.conf:

[FONT=monospace][COLOR=#000000]options it87 force_id=0x8728[/COLOR][/FONT]

[Filiprino]

Support will be lacking forever. Hardware vendors do not give any support. All has to be reverse engineered.

[Mat2]

Even in 2021 the desktop motherboard sensor support remains one of the poor areas of Linux hardware support.

I think that Windows support is not any better.

When it comes to temperature monitoring: well, most CPUs and GPUs nowadays have integrated temperature sensors, which are happily handled by respective kernel drivers (I don't know about Nouveau). Also, chipset temperatures are exposed via ACPI usually.

Voltage measurements: this requires not only support for respective SuperIO / etc. chip, but also information on how it is wired up. Assigning voltage rails to monitoring chip inputs and getting voltage divider parameters right is pretty much guesswork without vendor support. With trial and luck you can tune parameters to get readings that seem right, but they will not reliable. The voltage values may be useful for fancy HUDs, but not anything serious. It is just better to buy a multimeter and use it directly.

Fan control: many people try to get lower fan speeds, but setting the fan too low increases hardware wearout. Therefore this is not supported by vendors and public documentation is scarce.

Motherboard sensor support is not important for many people, after all.

[skeevy420]

I have a Gigabyte B550M DS3H so I'll give this a shot later on this evening and report back.

EDIT: Rebooted into Linux, did a quick run of sensors-detect, and

[FONT=monospace][COLOR=#000000]Found unknown chip with ID 0x8688[/COLOR][/FONT]

so I assume that I'll be good to go after I patch a kernel and compile it this evening.