CoolerControl/lm-sensors (Gigabyte board/it87)
i have the https://www.gigabyte.com/Motherboard/X870I-AORUS-PRO-ICE-rev-10 in my HTPC, which needs https://github.com/frankcrawford/it87 to work with CoolerControl
i'm running
bazzite-deck-gnome
i see 2 possible paths forward for getting it working
1. hope https://github.com/ublue-os/akmods/pull/261 lands
2. fork https://github.com/grandpares/ublue-image and add bazzite-deck-gnome to the images it builds
i feel like path 1 would be ideal, as it would solve this issue for more than just me, but i have no idea how likely it is to actually happen
if the answer to "will that pr land?" is "nope, never going to happen" then forking granpares's uBlue-it87 repo seems like the right path forward. i'd start by "scratching my own itch" and adding bazzite-deck-gnome, and then i'd want to add the other variants (bazzite-nvidia, bazzite-deck, bazzite-deck-nvidia, bazzite-gnome, bazzite-gnome-nvidia, bazzite-deck-gnome-nvidia)
so i guess my main question is just, "any chance https://github.com/ublue-os/akmods/pull/261 will land?"Solution:Jump to solution
https://github.com/ublue-os/akmods/pull/261#issuecomment-3450204361
antheas: It will never merge. As of Fedora 43 Bazzite will not be using akmods, so most akmod extras will be removed To that end, I patched the kernel with this so if you go to bazzite unstable with kernel 6.17 you will have this 🙂...
19 Replies
Solution
https://github.com/ublue-os/akmods/pull/261#issuecomment-3450204361
antheas: It will never merge. As of Fedora 43 Bazzite will not be using akmods, so most akmod extras will be removed To that end, I patched the kernel with this so if you go to bazzite unstable with kernel 6.17 you will have this 🙂 See https://github.com/bazzite-org/patchwork/commit/e1ce9d7de12b670fd15ba2d18629e2f1e776ad31
on
testing now, i was able to get the fans to show up for my motherboard by running
i then followed https://docs.bazzite.gg/Advanced/dracut-and-initramfs/?h=modprobe#if-you-just-plan-to-add-options-to-a-module-you-should-consider-using-a-karg to get it to persist on reboot and ran
and then created a new file /etc/modules-load.d/it87.conf with the contents
and the fans appear in sensors on reboot!i removed the it87 patch
i really do not like the ignore_resource_conflict
i might re-add it but remove all the motherboards they added to not need ignore_resource_conflict
to anyone who finds this thread in the future looking for a solution:
i'm back on stable now, i just wrote down the curves i made using coolercontrol and recreated them in bios settings
Perhaps I can help to elaborate why the
ignore_resource_conflict parameter is needed to begin with. It has to do with the fact that on gigabyte motherboards, the ACPI firmware reserves address ranges for the super ios on the boards regardless of whether or not it uses them. This in turn is what causes the conflict to begin with. Based on my reverse engineering and testing of boards with these chips the address space conflict only becomes an issue if the WMI methods embedded in the ACPI code are used by a system driver (though for many of these boards, the WMI methods aren't even hooked up). In the case of linux, there isn't one per se (though gigabyte-wmi does read temp sensors if loaded and wmi methods are hooked up) and even on windows, they don't use these access methods on modern systems. They instead use direct access methods similar to what the it87 driver is doing (while ignoring acpi conflicts). The only potential issue with including that parameter is that it could enable it for non gigabyte boards which use ite superio chips. In theory this could result in an issue, but the odds of it happening in a modern system are quite low. The DMI list inside the module itself is a solution designed to solve this by only enabling it for boards that have been tested first. Let me know how much more information you need to better understand what's going on and why.The WMI methods are partial in what way?
they are partial in the sense that most of them though present aren't hooked up inside of the acpi code itself. They return null or 0 as returns rather than any meaningful data. So while present, they don't actually make anything happen. Even on boards where they are hooked up unless a system driver is actively using them, they don't trigger any internal code that accesses the super ios outside of the wmi method that called them. The Gigabyte software itself ignores the wmi methods for the most part. There are only a handful of them that are even touched. The only one I've seen used for anything in recent software is their
gethwconfig method which contains the board identification numbers used to set up additional features including the superio access via hardware (the same way that it87 accesses it). For all intents and purposes on linux the address space reservation on gigabyte boards can be treated as dead. All of this was done via my own probing and disassembly of ACPI code present on the boards. The wmi method names were also pulled from the acpi code.
The curve setting issue that some may complain about also has nothing to do with an acpi or even uefi/bios conflict. It has to do with the fact that on some chips there are extra configuration parameters outside of what current it87 controls which inhibit control. The curves are actually stored in the EC registers and extended mmio memory of the chips themselves. So As long as it87 is the only driver loaded on the system and there isn't a driver actively using wmi methods (for the boards that have them connected), there is no concern for a conflict and the address reservation is mostly something that can be ignored. The only thing I have to say about including the parameter by default is that everything I've said so far applies to gigabyte boards. There is the small chance that non gigabyte boards will use it87 and that could lead to problems.So gigabyte on windows does not provide software that works with this chip?
they do, however it's via direct access the same way that it87 does it. They don't use the wmi methods present for chip control at all. They ignore them. The only wmi method they use is the gethwconfig method (which doesn't touch hardware anyways) to get two configuration id's that they then use to set up feature sets and fan control, etc.
I've mostly decoded what these ids are and how they work when I was implementing the rgb controller support in openrgb for the newer boards.
If there is no other driver claiming the addresses
What stops you from doing jt
well I'm working on adding the proper system support for the newer boards to it87 and so have combined that work into it. I'm making the statement here and now as it would be appropriate to explain how things currently work and why. I'm not the current maintainer of the it87 out of tree module as that would be Frank Crawford. Though I've been working with him to add proper support for things. But, for now, all you would need to do is include that out of tree module and then users can include the
acpi_enforce_resources=lax parameter if needed (as the kernel parameter, internal whitelist, and module parameter all do the same thing in this case). Then as boards get added or the internal code gets updated it can be updated in bazzite as needed.ok, so ACPI defines an operation region for the sensor, which blocks the native driver from working
then, in parallel, gigabyte does not provide an ACPI method for doing arbitrary accesses to that region
so youre left not being able to access the addresses as a native driver
yup
and how does the driver access the chip?
is it just fan speed?
it accesses io ports in the
0x0000000000000A45-0x0000000000000A46, and 0x0000000000000A65-0x0000000000000A66 ranges for most control operations (the 0x0000000000000A45-0x0000000000000A46range that ACPI reserves is only for the first superio even for dual super io boards). The it87 then manipulates various bytes to read fan, temperature, and voltage monitoring (doesn't set voltages), and then just writes fan curves/fan speeds depending on the chip configuration.
There are additional steps for accessing mmio but those aren't in the range of conflict so that information isn't relevant here as to set those up you still need conventional EC register access through the conflicting IO ranges.
Hopefully that clears everything up.if you read only and write only the speed in one go without needing to hold context
you can hold an acpi lock and remove the conflict check
very likely
well theres a lot more happening than just writing speed as there are up to 10 fan vectors to set up curves that then control the speed. So a simple lock doesn't work. It's why the module does what it does.
I'm currently on
unstable-43.20251027.2 which has modified it87 but not sunshine, is there a build with both it87 and sunshine?
it87 has a module whitelist but my gigabyte mobo is not in it, if it was would the module load automatically without having to use a kernel param? here is my mobo's (gigabyte b650m s2h) modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrF30:bd05/22/2024:br5.34:svnGigabyteTechnologyCo.,Ltd.:pnB650MS2H:pvr-CF:rvnGigabyteTechnologyCo.,Ltd.:rnB650MS2H:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:Yes it would