AFC 8.2.6.3 New Bug

[TheSQLGuru]

X17 R1 11980HK, 3080, 21H2 patched

First off, kudos for addressing AFC several issues with this build that I had been having but didn't have the drive to report to you (sorry).

STEPS TO CAUSE

1) Used zip file o overwrite all AFX files in my folder. Ancillary issue: this caused the loss of my existing Manual curves. Many past builds seem to do that too. I almost exclusively use pretty simple fan curves, with identical ones for CPU fan tied to CPU temp and GPU fan tied to GPU temp.

2) Created CPU fan curve. Fan and GUI did as expected.

3) Created GPU fan curve.

BUG

As soon as the GPU curve was completed (perhaps after I clicked back to the CPU fan option, uncertain of exact timing of the start), the fan curves disappeared and both fans started ramping up. They continued ramping up all the way to my overspeed max values - which is well past what you can actually get with Manual curves, as we have discussed before.

I have not yet attempted to reproduce this, but will do so now and report back.

[TheSQLGuru]

Upon restarting AFC the following was noted:

A) The 3rd and 4th fans, which were previously labeled SSD 1 and SSD 2, changed names to be CPU 3 and GPU 4. I may have noticed this in the past, uncertain. i) These two fans SHOULD be labeled CPU 2 and GPU 2, as the X17 does have 4 fans on each side. I currently cannot remember which heat pipe sections they are "associated" with, but I can get that from the X17 Service Manual. i) Very briefly, the 4th tmp fan speed went to 900 rpm for a few seconds, then returned and remained at 0.

B) Both CPU and GPU fan curves were gone. i) CPU fan curve was default linear line, and that fan responded as expected (red dot and fan speed prepresentative of where the temp/speed line was at) ii) GPU fan curve was blank, and GPU fan ramped up to max. While writing this up, the GPU fan speed actually reduced to a reasonable value, then went back to max after some time with no change in computer usage.

I apologize, but I have a family commitment and cannot get you screenshots. I know that I have posted my simple fan curves in the past on prior issues though if you get a chance to work this before I can update this ticket with new ones.

[TheSQLGuru]

POSSIBLY NEW BUG:

I just noticed that I have TWO alienfan-gui.exe copies running currently. That should not be allowed.

The second of the two shut down as expected when I X'd out. The 2nd did NOT close when I X'd out.

Using the Exit button DID close the initially-opened app.

[T-Troll]

1. It's impossible. Configuration does not impact by update, it's into Registry. But - new user have cleaned one, it's user-based.
2. and so. Please use alienfx-config backup console command and share afx-fans.reg here -i'll check what you have into configuration.

Yes, after some update, fans now have names by it's function. Number is a fan number into the system, as reported by BIOS, so 3-4 is NOT a bug, but hint.

Please keep in mind, fan control is INDIRECT for this hardware, so real RPM controlled by BIOS, i just add some hints and flexibility for it. I can only increase RPM, not decrease it.

2 copies is OK, it's useful sometimes. They do not interfere to each other, just consume a bit more CPU.

Yes. MANY people ask me to make this reaction to "x" - this apps intended to run all the time, so it's the protection against accidentally closing it. Quit only possible via "Exit" button, application top or tray menu. Even ALT-F4 will minimize it.

[TheSQLGuru]

Wonkiness continues with this build.

A) While adjusting CPU undervolt and benchmarking, I set AFC to Level 4 to keep fans high. I experienced several crashes of various benchmarking apps during this cycle, including a number of BSOD's.

It came to be that no matter whether AFC was running or not, my fans would go to super-max speed (well above Level 4's numbers). When Win started, fans went to max - and I do not have AFC set to start on boot. If I started AFC and changed the level numbers, it seemed to behave as expected. When I changed to Manual, it ignored that and blasted to max speed again. This was repeatable over reboot cycle too.

Digging though the Doc files (very helpful, btw!!), I found there was an "Unlock" command, which would enable manual fan control. I tried that, and sure enough I was able to regain the use of Manual mode. YAAAAYYY! :-D

Oh, one further thing. During one of the periods when I was on Manual, the fan speeds for fans 3 and 4 went thousands of RPM above their max boost levels!! Over 6K for one and about 5500 for the other. These are the little fans that blow out the sides.

B) Before starting my undervolting exercise, AFC yet again lost my fan curves. This has been a recurring theme for me for probably every build I have tried.

C) While doing research, I compared the current reg export with one from earlier this year (both attached). I noticed two new entries:

"DPTF"=dword:00000000 "KeepSystemMode"=dword:00000001

I am curious what those are for. Actually, I am curious about all of the reg values. Could you add that info to the Doc files?

D) Does the fact that the Power Levels are not in the same numerical order as their names? I would guess not, but ask because I have noticed some inconsistency between the level and the fan speeds. AFC_Reg_Exports.zip

[T-Troll]

I'll start from the last.

DPTF - this flag force DPTF (ESIF) name check. It's long operation, so i do it once only - if driver present and can be run, until read.

KeepMode - it's about your point "A". Normally (if it set), app store power mode at start and restore it back at quit. In case it is not checked (0) - app will keep last mode selected into it after quit. So you can use it to switch default system mode (as well as CLI). It's in Settings, in fact.

Level order - yes, it is. First level order created based on BIOS report order, but later registry sort it, so it will be different. In fact, it's intended to be renamed, so it's important to keep the same order all the time.

Curves... This just CAN NOT be like this. Source is other, most probably unchecked sensors. I see you have it in Registry.

BTW, some systems can report incorrect RPMs for a second, so it's OK. It is not used anyway, just shown. ^_^

[TheSQLGuru]

Thanks for the responses!

When you say "Source is other, most probably unchecked sensors.", what, exactly, do you mean there?

I may have found a reason why fans 3 and 4 run up to super-max speeds: those two have no "curve" for either temperature (CPU or GPU). Always in the past I would have a default curve which was a straight green line from lower-left corner to upper-right corner. That is missing for fans 3 and 4 for both temperatures. Could this be the cause of my behavior? In any case, is there a way I can get the default curve to show so I can adjust it? Or perhaps just copy the curve I use for one of the other fan/temp pairs to these two?

[T-Troll]

When you say "Source is other, most probably unchecked sensors.", what, exactly, do you mean there?

Curve deletion now is a 2-stage process. In case you just uncheck sensor, curve still in memory, but not shown/used in calculations. But it will be removed completely at application quit (not saved in config, in fact). So do not do it except for experiments, or you lost it.

those two have no "curve" for either temperature (CPU or GPU).

In this case, fan fully controlled by BIOS and not touched by app. BIOS decide what sensors and values it uses (fan name give a hint about it).

Always in the past I would have a default curve which was a straight green line from lower-left corner to upper-right corner.

It's different case. Boost will be controlled by app, and have some boost value all the time.

In any case, is there a way I can get the default curve to show so I can adjust it?

In the first case - no, it's 100% BIOS-defined, and i have no data about it. Into the second case - yes, it's a common control case. But, anyway, you can't set it below BIOS value.

Better set common S-shaped curve for it with 60-70C border.