[Guide] How to control fans on Dell Laptops under Windows

Indeed, this seems to indicate that a small tweak is needed get the Linux code to support the 9570.

There is a patch in the discussion that applies to dell-smm-hwmon.c (https://github.com/torvalds/linux/blob/master/drivers/hwmon/dell-smm-hwmon.c), towards the bottom where they basically have a list of Dell devices or classes of devices spelled out. Unfortunately, the code for the Windows Dell SMM IO driver that we have (https://github.com/424778940z/bzh-windrv-dell-smm-io/tree/master/bzh_dell_smm_io) doesn't seem to have anything that corresponds to this.

I'm mostly stringing together work done by others here, I've never done any low-level driver stuff, so I'm basically at a loss.

 

@Aaron44126 I spoke to a Linux 9570 owner, the one from the patch discussion link, and he says, that the dell-smm-hwmon works fine under Linux to disable the EC fan control on the 9570, but only if you use the "force=1" option, which this Windows driver seems to lack.

I looked into the windows driver port, and I guess this part fails:

https://github.com/424778940z/bzh-w...aster/bzh_dell_smm_io/bzh_dell_smm_lowlevel.h

// did it work ?
if ((sc->cmd == cmd && sc->data == data && sc->stat1 == stat1 && sc->stat2 == stat2) // function not supported
|| ((cmd & 0xffff) == 0xffff)) // or invalid device
status = 0;

maybe? So it thinks the 9570 is not a supported device, for whatever reason maybe and doesnt load the driver, even it might work? Could you maybe implement a force option to skip this check?

 

I haven't tried to build the driver yet (I've just been working with the binary files attached to the very first post of this thread). But, I see there is a Visual Studio solution file there, so assuming that I can just open it up and easily build it from source, I can produce a version that skips this check entirely and we can see how that goes.

[Edit]
It's not a clean open-and-build. I got through the first few build errors (having to include Windows Driver Kit stuff) but more keep coming. Currently blocked on one claiming that I do not have Windows kernel-mode driver build tools installed, even though I do have the WDK installed. Not sure how deep I'll go with this.

 

Scheduled tasks for automatic fan control.

This is what I have found that works...

1. Disable EC fan control at login.
I made a task with "At log on" of "specific user" (myself). It runs this script.

Code:

@ECHO OFF

ECHO Waiting for SpeedFan...
START "" /B "C:\Program Files (x86)\SpeedFan\speedfan.exe"
sleep 75
DellFanCmd.exe ec-disable
pause

This basically starts SpeedFan, waits 75 seconds (plenty of time for it to load all of the sensors and get ready to go), and then disables EC fan control. SpeedFan takes over right away. I have SpeedFan configured to start minimized.
Note, the "sleep" command is not built in to Windows. You can get it by installing the Windows Server 2003 resource kit. https://www.microsoft.com/en-us/download/details.aspx?id=17657
The "pause" command just adds a "press any key to continue" prompt before the command window goes away. So, I can see the output of DellFanCmd before it automatically disappears.

The solution survives sleep but it does not survive hibernate. So...
2. Disable EC fan upon resume from hibernate.
I made a task with "On an event" trigger. It is set to run only if I am already logged in. The event is, Log: System, Source: Kernel-Power, Event ID: 107. It just runs: DellFanCmd.exe ec-disable
(SpeedFan is already running.)

3. Return fan control to the EC upon logout.
The trickiest one. There's no clear event to trigger off of for logout. Also, I want to make sure that it is only when *I* log out and not other users (I'm not the only one who uses my laptop).

I ended up with this. A task set to run "whether or not I am logged in", with a custom event filter trigger:

Code:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">
        *[System[Provider[@Name='Microsoft-Windows-Winlogon'] and (EventID=7002)]]
        and
        *[EventData[Data[@Name='UserSid'] and (Data='S-1-5-21-1686773459-1707497739-4133313906-1001')]]
    </Select>
  </Query>
</QueryList>

This captures a logout event entered by Microsoft's Windows telemetry service. The Data='S.....' is my Windows account SID. You'll have to adjust it for your own SID.
It just runs: DellFanCmd.exe ec-enable


When setting up scheduled tasks, pay attention to the option that is enabled by default which prevents them from running if the system is on battery power. All tasks need to be set to run with "highest privileges".

[Edit]
For #3, I also added it to the "Shutdown script" (gpedit -> Windows settings -> Scripts) because the scheduled task will (sometimes?) fail when the system is shutting down or rebooting.

 

Gentlemen:

Sorry to be behind here -- have errands/chores today. When I get back, I'll try the new version on mny 9360 (i7 8550 -- 8th Gen, I believe, but in the older Dell chassis . . . and mainboard?). I can also test this on my 9560, which is one generation older than Maffle's machine (7th Gen, I think, i7 7700HQ).

Will report as soon as I do so. Meanwhile, best of luck with the 70 series fix. It'd sure be nice if that proves to be possible.

Mike

 

I just tried it on a Dell Precision 7510 (6th gen) and was not able to get the driver to load. Cut-off point may be older than I thought... I reviewed the thread again and found @alexhawker's comment that it hasn't worked with any machines in the last six years, but then I saw other posts stating that it works with the Precision 5520 and XPS 9550, which aren't that old.

Side note, if anyone finds that the "Dell fan utility" (GUI app) works but the console app doesn't, then there is still some sort of bug in the console app, I'd be interested to know that.

 

Aaron:

Second Beta Report -- based on the second command line utility posted.

Overall, tantalizingly close . . . but not yet.

First, I ran the utility manually this time with admin privileges with testsigning off, and it does both grab control of the fans, and does run them up to 100% (using the first ec-disable command).

Here's the cmd line story:



It looks like success, particularly if the error is because there's only one fan in the machine.

But, Speedfan not only doesn't grab control, it seemed to go rouge -- it lost track of everything, dumped the existing fan profiles and reported a temp of 88c -- Throttlestop said 26. Here's a shot of that strange abomination:



Notice that you don't see any of the usual stuff here -- no cpu temps, not fan control option, no up/down arrows. The green temp is Throttlestop package temp -- the 88c is Speedfan gone wild.

Couple of reboots and some work with the old GUI with testsigning on recovered more useful control of the fans (i.e., not continuously running at 100%), and some checking in Speedfan revealed the the "Dell Control" check box in options had been cleared. What?? How'd that happen?

It's vaguely possible that I somehow screwed that up, but I don't think so. I did turn off debug and uncheck ISA yesterday, as neither seemed to be needed (just experimenting around). MAYBE I had a slip of the mouse? Didn't notice it in use this AM, so I don't think it was me, but it's not beyond possibility -- the machine was mostly at idle. Took a while to rebuild the fan profiles and such from scratch, so I'll wait to hear from you before I try again. I'm well out of my depth here on causes, though I'm enjoying your exchange with Maffle on the general topic. But if I just need to try again, I'm game.

Given that we now know you can grab control and run the 9360's fan up to 100%, I think this is successful as proof of concept, and a learning step on the exchange/interface with Speedfan -- whether for you or for me is not yet clear. Entirely possible I did something stupid. Should be around tomorrow with a cold rain out -- so will await word and then get at it.

This looks very much like it can be made to work up to at least the 9360 (Fall 2017) with the i7 8550 U Quad Core. Once we get that working, I'll try the 9560 for you.

Best,
Mike

 

Oh wait . . . I forgot. I uninstalled the C++ setup yesterday just to get back to the initial condition. Should I try again with that?

Also, Speedfan had accurate temps for each core before, tracking HWMon. Now it's reporting individual core temps like 11 C, which is way off. I could set offsets, but that's another oddity.

Hmmm . . .rechecked ISA and debug options again in speedfan, and I see Speedfan apparently making use of them -- so maybe I did something dumb here, and then just didn't notice?

Embarrasing . . . shouldn't mess with things I don't understand?

Could always just blow Speedfan away, reinstall and reconfigure . . .

Mike

 

First off, it shouldn't matter if you uninstalled the Visual C++ runtime, if there was an issue with that then the program would not even run.

Next, if the program goes out of whack, a full shutdown should reset everything back to normal. Also, visit Windows Power Options / "Choose what the power buttons do" (on the left) and make sure that fast startup is disabled while working on this. If you don't do this, a shut down actually just performs a logout+hibernate and it could leave behind some residual stuff.

The only thing that I can think of, really, is that issuing a command regarding the non-existent fan threw things out of whack somehow. I didn't really think about the fact that some of these systems are single-fan. All of the systems that I have access to are dual-fan.

So, here is what I suggest. I'm leaving a build here that will leave the second fan alone. Give it a try and see if things are different. If you run into the same problem, fully shut down the system (not just a reboot). Try again with the "alternate" method. If either method works, I'll see about either dynamically detecting how many fans there are or adding a command line option to specify it if I can't figure that out. (Curious, what does the GUI app look like in your case, does it indicate that the second fan is missing?)

Not sure what to make of SpeedFan temperature reporting. Obviously, other apps are able to read the proper temperature. I've been messing with it lots today, including doing things like turning EC control on and off on the fly while SpeedFan is attempting to manage the fans, and I haven't run into anything like this.

[Edit] Binary removed, see https://github.com/AaronKelley/DellFanCmd/releases

 

Morning Aaron:

This is excellent. I have a new test subject, and useful experiments to work on. Will do as you advise. And will likely conduct some experiments to see if something I did screwed up Speedfan somehow (following which I pledge to stop introducing stray variables into the experiment until we're done).

After a first test on the one-fan variant, I'll likely reinstall Speedfan and see what happens. Set up offsets for the fans last night (I often find the Speedfan reports different values than the BIOS does on desktop machines, so that's familiar). Everything seems to work fine. But the result when I ran your second version was . . . out there.

Therefore, after I do all that, I'll run the dual fan version again and see if the error is repeatable. That should tell us what we need to know. That may also take a bit of time, as I could well have to rebuild Speedfan profiles a couple of times.

Will report back when that's all done. And if the "one fan" version works, I'll give you and early report on that just so you know where we're headed.