emansom
commented
1 month ago Motherboard says it's an IT8689E:
Open emansom opened 1 month ago
emansom
commented
1 month ago Motherboard says it's an IT8689E:
frankcrawford
commented
1 month ago Thanks for that. I'll look at it in the next few days.
I think that chip is already supported, so is the issue you are seeing that the driver won't load? I guess I'll check through the attachments.
Have you attached them, as I can't see them here?
emansom
commented
1 month ago I think that chip is already supported, so is the issue you are seeing that the driver won't load? I guess I'll check through the attachments.
Yes, it won't load automatically.
A dmi match like done for other motherboards might work looking at code, though not sure. Will test with patching.
Have you attached them, as I can't see them here?
I wrapped them in a </details> block, simply click on them.
emansom
commented
1 month ago Digging further, it seems I was testing with the upstream/built-in version of this module inside the kernel (CachyOS kernel).
Now building a kernel without the built-in module compiled in, so I can test a DKMS built one.
emansom
commented
1 month ago Any plans on submitting patches to LKML to update the upstream/built-in it87 driver?
emansom
commented
1 month ago Testing the DKMS built one (latest git, using AUR package it87-dkms-git) results in the following:
frankcrawford
commented
1 month ago @emansom have you rebooted the system since the DKMS rebuild? While it moves the original module out of the way, it doesn't always manage to unload it cleanly.
The error you are seeing sounds like the LKML version is still loaded.
If you don't want to reboot you could try rmmod it87 followed by modprobe it87
As for upstreaming it, yes, that is going on, but every difference needs to be justified, so it is a very slow process, especially as I didn't write lots of those differences, and need to go through them very carefully.
frankcrawford
commented
1 month ago Oh, looking at the code a bit further, currently that board doesn't automatically ignore ACPI issues. Can you check dmesg and see if you have a line like
ACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20230628/utaddress-204)If you do see that, add the option ignore_resource_conflict=1, i.e. run modprobe it87 ignore_resource_conflict=1 and let me know if that works. If it does, you can temporarily add that option into /etc/modprobe.d/it87.conf (or equivalent).
I can then get you to do a few tests to see if there are any issues making it a permanent fix.
emansom
commented
1 month ago @emansom have you rebooted the system since the DKMS rebuild? While it moves the original module out of the way, it doesn't always manage to unload it cleanly.
Yes. I rebooted after I recompiled the kernel with the built-in module disabled.
The error you are seeing sounds like the LKML version is still loaded.
No module is loaded. As you can see from the output of lsmod in my last comment.
As for upstreaming it, yes, that is going on, but every difference needs to be justified, so it is a very slow process, especially as I didn't write lots of those differences, and need to go through them very carefully.
Appreciate it that you're going down that rabbit hole!
emansom
commented
1 month ago Oh, looking at the code a bit further, currently that board doesn't automatically ignore ACPI issues. Can you check
dmesgand see if you have a line likeACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20230628/utaddress-204)
Yep, that's it! I can see similar lines to that in the dmesg output:
If you do see that, add the option
ignore_resource_conflict=1, i.e. runmodprobe it87 ignore_resource_conflict=1and let me know if that works. If it does, you can temporarily add that option into /etc/modprobe.d/it87.conf (or equivalent).I can then get you to do a few tests to see if there are any issues making it a permanent fix.
This also works as expected! Output of shell session:
emansom
commented
1 month ago Output of lshw:
There are three versions of this exact motherboard. This motherboard is a rev 1.3 model. I'm not entirely sure if the other revisions have different ITE chips and have no way to verify this myself. I also see no easy way to identify the revision of this board from DMI/ACPI info.
emansom
commented
1 month ago I think gigabyte_wmi might be the cause of the conflict, not sure.
frankcrawford
commented
1 month ago @emansom the actual conflict is basically a stupid setup by Gigabyte, as they have claimed the address space, but often don't use it. In this case they are almost correct, as gigabyte_wmi is the "official way" to look up the info, but misses most information. For many boards gigabyte_wmi doesn't work, but they still have the address space claimed.
Anyway, that is just an aside, the possible "multiple" access to the same memory region is a risk, but I am yet to have a report that it actually caused an issue. However, can you do some further and monitoring for a couple of days, to see if it is all okay, and then send me some additional items if you think it should be automatically enabled.
What I need is cat /sys/class/dmi/id/board_vendor and cat /sys/class/dmi/id/board_name for the hardware match.
emansom
commented
1 month ago @emansom the actual conflict is basically a stupid setup by Gigabyte, as they have claimed the address space, but often don't use it. In this case they are almost correct, as
gigabyte_wmiis the "official way" to look up the info, but misses most information. For many boardsgigabyte_wmidoesn't work, but they still have the address space claimed.
Would blacklisting/not compiling the gigabyte_wmi module be a safer option?
Anyway, that is just an aside, the possible "multiple" access to the same memory region is a risk, but I am yet to have a report that it actually caused an issue. However, can you do some further and monitoring for a couple of days, to see if it is all okay, and then send me some additional items if you think it should be automatically enabled.
I tried yesterday to control the PWM of the fans via fan2go with both modules active (gigabyte_wmi loaded and this fork it87 via DKMS active with ignore_resource_conflict=1). Firstly it calibrated to all the wrong min and max PWM values, and even when triggering manually via the regular hwmon paths: it didn't change the RPM of the fans in the slightest.
From within the UEFI/BIOS I have configured a custom fan profile for the CPU fan, and changed settings for the case fans to follow PCH temperatures instead. Would this be conflicting if software takes over PWM control? My understanding was that once the system boots, and fan2go runs: the UEFI based fan controller should stop by it self?
And if the UEFI and OS based software control are in conflict with each other: how do I disable the UEFI based fan control?
What I need is
cat /sys/class/dmi/id/board_vendorandcat /sys/class/dmi/id/board_namefor the hardware match.
Gigabyte Technology Co., Ltd.B650M GAMING X AXFurther digging. This is weird:
22:46 root@am5ws ~# echo 1 > /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm1_enable
22:47 root@am5ws ~# cat /sys/devices/platform/it87.2624/hwmon/hwmon5/pwm1_enable
0
22:47 root@am5ws ~# @emansom unfortunately gigabyte_wmi doesn't really affect whether the BIOS claims the addresses. You can blacklist it if you wish, but that does not affect the error, nor how the BIOS accesses the ports.
Now, as for the fan management, currently it will probably not work, as Gigabyte have done something strange. You can check issue #11 for more details. Another project does seem to have a fix, which I am looking at, and will see what I can do about it in the near future. In the meantime you can try the work-around given in the issue.
frankcrawford
commented
1 month ago I've added this model to automatically set ignore_resource_conflict=1 in the latest commit.
emansom
commented
1 month ago Do you by chance know any USB (preferably header based) or PCI-e based PWM controllers, available as consumer products that have good quality mainline kernel drivers?
frankcrawford
commented
1 month ago Unfortunately no.
Per instructions in the README, i'm providing information to hopefully get fan control on the B650M GAMING X AX (rev 1.3) working.
Output of commands:
sensors-detect
```shell 09:45 ewout@am5ws ~% sudo sensors-detect # sensors-detect version 3.6.0+git # System: Gigabyte Technology Co., Ltd. B650M GAMING X AX [Default string] # Kernel: 6.9.3-1-cachyos x86_64 # Processor: AMD Ryzen 5 7600 6-Core Processor (25/97/2) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 17h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Hygon Family 18h thermal sensors... No AMD Family 19h thermal sensors... No Intel digital thermal sensor... No Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor... No VIA Nano thermal sensor... No 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'... No Some systems (mainly servers) implement IPMI, a set of common interfaces through which system health data may be retrieved, amongst other things. We first try to get the information from SMBIOS. If we don't find it there, we have to read from arbitrary I/O ports to probe for such interfaces. This is normally safe. Do you want to scan for IPMI interfaces? (YES/no): ^C 09:53 ewout@am5ws ~% ```sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
```shell 09:48 ewout@am5ws ~% sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7 [sudo] wachtwoord voor ewout: WARNING! Running this program can cause system crashes, data loss and worse! I will probe address register 0x2e and data register 0x2f. Probing bank 7 using bank register 0x07. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 86 89 02 00 2e 20 b3 00 00 00 80 30 88 40 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 0a 00 20 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 20 00 00 17 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 c0 00 00 00 00 c0: 01 00 00 40 00 ff ff ff 01 00 00 00 00 68 00 00 d0: b5 00 08 0a 00 fd ff ff 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 50 00 20 12 49 00 00 0a 7c f0: 00 00 00 00 00 00 0d 00 00 d0 49 60 00 6e 00 ff 09:49 ewout@am5ws ~% ```Can't determine the device address to run the third command, as it's missing from the output of
sensors-detect.