I have a Gigabyte Z790 UD/i5-12600KF, let me know what/how to test

If it’s not a machine you use / care about then just an RDP with admin would work, and I figure out the rest.

Otherwise, I can prepare a test binary to see how far we get, and hopefully it won’t devolve into poking at random stuff in RWEverything.

If it’s not a machine you use / care about then just an RDP with admin would work, and I figure out the rest.

Otherwise, I can prepare a test binary to see how far we get, and hopefully it won’t devolve into poking at random stuff in RWEverything.

It's your personal machine, so a test binary would be preferable.

I tried installing PawnIO and got this error:

Tried it with and without unrestricted editon.

Tried restarting, reinstalling, no luck.

Event viewer info:

The description for Event ID 26 from source Application Popup cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event: 

\??\C:\Program Files\PawnIO\PawnIO.sys failed to load

The message resource is present but the message was not found in the message table

Event viewer error:

The PawnIO Kernel Driver service failed to start due to the following error: 
Insufficient system resources exist to complete the requested service.

Running FaceIT AC by any chance?

Hi there
I do have Gigabyte Hardware (Intel, Z490 Vision D) as my main computer.
I won't have much time to investigate anything, but if there is something easy that you want to check, maybe I can look at it. (No promises though)

have Gigabyte AMD X670E with IT8792E as my main machine... willing to test with binaries if needed

Running FaceIT AC by any chance?

@namazso I use FaceIT AC. Is there a workaround? I recently got the defender issue with winring (openrgb and fancontrol) and I saw that in the new versions they use pawnio. My MB is an Asus Z170-k.

@yqfQiQkH0OhC5 short of uninstalling / unloading faceit, no, not for now. I guess you could write them in hopes of whitelisting, but likely the same signer also signed some vulnerable drivers at some point. So a solution from this side needs to wait for me to get another signer which will take a bit of time.

@namazso Thanks for your efforts and your time. I'm looking forward to that.

Is there any chance that Asus motherboard e.g. TUF B850 also not fully supported by PawnIO? I had installed PawnIO and together with FanControl. But it couldn't detect any motherboard fan controllers.
It shouldn't be windows defender issues, as I whitelisted FanControl and it works when I rollback to previous FanControl versions.

@simy1129 It is intended to be supported. The only intentional regression is losing the ability to control MB fans on Gigabyte, and restoring that is what this PR is about. Everything else is a bug in something that is intended to work, and should be reported as such.

@yqfQiQkH0OhC5 short of uninstalling / unloading faceit, no, not for now. I guess you could write them in hopes of whitelisting, but likely the same signer also signed some vulnerable drivers at some point. So a solution from this side needs to wait for me to get another signer which will take a bit of time.

Try reaching out to HYTE. They told me when the WinRing0 stuff first started becoming an issue that they were considering signing a modified WinRing0 that only allowed admin apps access. If anyone was willing to sign a replacement for WinRing0 I would think they would be the ones.

@CalcProgrammer1 This is being tracked at namazso/PawnIO.Setup#1 and a solution might be on the horizon. The complicated licensing model of PawnIO is meant to subsidize a proper signing certificate. However, I'll keep HYTE in mind if anything falls through.

Hi,

As a long time user of FanControl (and therefore LibreHardwareMonitor indirectly) I might be able to help test this issue.

I have a GIGABYTE X870E AORUS PRO (with ITE IT8696E/AX + ITE IT87952E Combo SuperIO chips) which was working well with the older version of FanControl.

Now I have incomplete Fan Control in that FanControl v240 can see and monitor all the fan headers, I can only control around half of them. The ones that don't fully work no longer respond to fan speed inputs.

If I can be of help, please let me know. You can use Signal via SimonZerafa.64 or Mastodon via SimonZerafa@Infosec.Exchange to contact me, or via this thread.

Kind Regards

Simon Zerafa

Sorry, I was a bit busy dealing with other stuff. Here's a test program based on this current branch: untitled5.zip

Run from terminal, as admin, and copy output (or you can also redirect it to a file, whatever works).

In theory it should also enable your fan control if disabled, and disable if it's enabled (like if you run it a second time).

output.txt

I'm doing calibration and testing, but I don't think its working

All three of my relevant fans are not responding to control. Also restarted FanControl.

Yeah, the dump of the second chip is just all FFs. Still, this is working surprisingly more than I expected of completely untested code. It finds the chips, their base addresses, and actually reads something that vaguely looks like some flash memory, since empty values are FF and not 00 like how it'd be with normal computer RAM. Plus it even has some sort of data at the beginning of the first chip. I think I'll compare to the original LHM code to see if I missed some step about enabling the second controller somehow.

@namazso same issue with a X570 AORUS MASTER. Has an ITE IT8688E and a ITE IT8792E for fan control.

Don't know if it helps, but here's some info from my system, too:
X470 AORUS ULTRA GAMING-CF, ITE IT8686

output.txt

I did try to boot without HWinfo as startup, run the utility, but got the same outcome.
I also use OpenRGB, but as far as I know, that's stil on winring0. For the test thou, I also stopped OpenRGB as well.
ZenTimmings is also linked to pawnio, but it was not running during the test and it does not check for fan sensors anyway.
output_1.txt

I see. It seems that whatever is going on, something is blocking access to the second superio. Something else you can do is run my python utility on a linux live usb and capture data that way. And if your motherboard has system 7 and system 8 pumps then it stands to reason that your system also has the third chip for those two headers. Another thing you could try I guess is a full shutdown and removal of power for 10 seconds or so then start back up again.

@cosmintnt LHM and therefore FanControl supports RAM temperature since a couple of months.
Is it not working for you or did you not see the update / sensors yet ? Please let me know.
You may have to enable Memory in FanControl settings.

No GCC installed, but I'm running HWinfo and FanControl on the same time, as I use a FC plugin to get RAM temperature from HWinfo and adjust RAM fan based on dimm's temperature.

@Blacktempel - Thanks for the headsup, I was doing it for so long with HWinfo plug in ...

@TsunamiMommy: is there a way to chat somewhere about the topic? to avoid clutering the thread with relatively off-topic subject (like guiding me with Linux live usb, your script and trying to find what's not working). For sure we'll share possible findings in a more condensed way than replaying here back and forth.

@namazso Could you enable Discussions on this repository ?

Enabled. This repo wasn’t meant to be for end users originally which is why it was disabled.

untitled5 helped me,thank you.
Motherboard: Gigabyte B500 Aorus Pro AC
output_enabled.txt

based on some of the previous chatter about running this while GCC or FanControl was enabled, I decided to uninstall GCC, prevent FanControl from starting, rebooted, and then I ran your tool 3 consecutive times because I noticed the outputs changed between each run. I don't know if this provides more useful context. my 2nd chip still seems to only show FFs though

attached in numbered order.

output1.txt
output2.txt
output3.txt

Yeah. The current utility for windows seems to be having trouble with setting up the window properly for reading the second superio. I'm working on seeing what can be done. As I've developed a tool based on this MR that does the same thing in linux, and it doesn't seem to have this problem. So there needs to be work done on a better windows utility to dump the memory contents.

Note on windows, the actual service that drove the fans in various MBs was EasyTuneEngineService for me, which can be installed even if you don't have GCC (e.g. SIV installed it for me).

It's generally not the UI program like GCC or SIV that drives the fans, it's the service. I'd check if that's there, or maybe something renamed as they change the names of this stuff every few years.

The utility indeed had a bug, but it was only using the size of the first one for dumping the second superio, but that would only result in dumps where there is no first MMIO detected, causing empty dumps for the second one. However most of the logic doing the memory access is in the module, so should be alright. Especially since some people reported success.

Anyway, I added Chip ID printout to the module, and made a new test program:
untitled5.zip

Not sure how much it will help though

thanks for the updated tool. no luck with my 2nd chip, unfortunately

I'm going to get a live Linux booted up and try the Python tool here in a minute

output.txt

log.txt
tested again,Gigabyte B500 Aorus Pro AC, worked.

I have a little bit of a side bar going with @TsunamiMommy in frankcrawford/it87#64 and we have made some progress on my 2nd chip... I think I will let them chime in with the full details when the time is right as I don't want to misrepresent anything.

I will say, if you want to try to use scripts from that thread in a live boot Linux environment, be aware that you must disable Secure Boot for proper access to the hardware to be permitted.

Yeah it appears that ECIO and the standard ISA bridge access are not mutual. It appears that some boards use one method or the other but not both at the same time. This likely explains why some aren't getting access to the superio.

But then the question remains how would it have worked with the original WinRing0 implementation in LHM? it was doing pretty much exactly the same as what I did here.

Oh, actually that's simple to explain: ECIO was added to LHM at some point, after I started porting a bunch of stuff over: LibreHardwareMonitor/LibreHardwareMonitor#1313

Yeah I guess that's a whole different thing to cover then

Yup. So it did help us figure it out. Because my gp utility can access ECIO if smfi isn't supported. And I saw valid data there. That's how I came to that conclusion.

Hey @namazso did you have a LHM branch going with this module? Otherwise I'll start implementing it.

Seems to be pretty straight forward compared to the old implementation, but I wouldn't mind a few guidelines if there is any gotchas. Like which MMIOState to use in which case. The "original" for the old "restore" method that's obvious, but the other ones I'm not so sure.

I don’t have any, so feel free to! You’ll probably want to revert the file deletion from my original PR, and use the module from here for the ISA bridge version, and attempt just using the LpcIO for the ECIO version. The later may need some extra work to be Dispose-correct.

As for which MMIO state, you’d probably want to check if 4E is enabled already, and if not then just enable it. My implementation is mostly based on GCC’s so it may be somewhat different to the original LHM code.

Opened a LHM PR draft

Need all the review I can get, just put the code in there but obv I couldn't test anything. Feedback/help welcomed.

Has anyone actually tested the bridge code on intel systems?

So, something that needs to be addressed with this code is that based on some testing and code verification I've done, intel systems cannot support two simultaneous windows. So that behavior will need to be changed. I've been working with a few linux users with intel systems and the behavior from this implementation (that I've mirrored in the it87 driver), only keep the last mmio address written to the 0x98 base address register on the intel isa bridge. This by default won't work because if you try to write an additional address there it will replace the previous one and keep only that window active. There may be additional steps for skylake platforms as well, but I'm still testing it.