Page 1 of 1
Fan control tool: bug reports
Posted: Fri Dec 16, 2005 1:11 pm
by geoffrey
Shimodax had made a really great tool, and we all owe him huge thanks.
This thread is just meant to help focus on any possible bugs, because the original thread has become too long for this purpose. Ideally each report should be a separate message.
Posted: Fri Dec 16, 2005 1:30 pm
by geoffrey
This bug is discussed in the tool's original thread:
Approximately six times per second, an error is written to the WinXP System Event Log while fancontrol is running in Smart mode. The text of the error is:
\Device\ACPIEC: The embedded controller (EC) hardware returned data when none was requested. This may indicate that the BIOS is incorectly trying to access the EC without syncronizing with the OS. The data is being ignored.
This bug, which may be in the WinIO.dll and .sys drivers, appears to prevent the hard disk from spinning down, e.g. during battery operation. This is because the system log is continually being updated, causing periodic disk access.
Posted: Sat Dec 17, 2005 2:51 am
by BillMorrow
good thought (bug reporting, here)
and
good point (IRT HDD running all the time=byebye battery life)
Posted: Sun Dec 18, 2005 2:00 am
by CoolDragon
I am using the 0.18 version, but sometimes, it starts up in manual mode, not BIOS, not smart.
Posted: Sun Dec 18, 2005 11:26 pm
by danda821
Thank for the good job of Shimodax. Sometime I get the following error:
Set fan control to 0x03, Result: COULD NOT SET FAN STATE !!!.
But when I switch to BIOS, then back to smart mode, it comes back to normal.
Posted: Mon Dec 19, 2005 1:08 pm
by christopher_wolf
I have gotten that error sometimes too; don't know what it could be.
Posted: Tue Dec 20, 2005 2:52 am
by pipspeak
Always starts up in manual mode fan level 7 for me, except the fan does not run at level 7, which is odd.
I also get the event errors filling up the system log.
Most perplexing (and no real fault of the utility) is that fancontrol seems to not quite be monitoring what the machine is monitoring in terms of temperature. On Bios control, my fan for the last few hours has been running at level 4 with the following numbers from fancontrol:
CPU 43°C (0x78)
APS 42°C (0x79)
PCM 30°C (0x7a)
GPU 48°C (0x7b)
BUS 43°C (0xc0)
PCI 45°C (0xc1)
PWR 45°C (0xc2)
Now those numbers do not warrant 4200rpm IMO. Moreover, with pretty much the same figures yesterday, the fan was humming at only level 2 on bios control. No idea what changed today to make the bios kick up the speed, though I did notice that the fan sped up and stayed up after a virus scan was done, even though the temperatures came down. Hopefully someone can find the mystery sensor that causes such mysterious bios control.
Posted: Sat Dec 31, 2005 1:53 pm
by Aristotle11
Nearly fried my CPU after fancontrol 0.18 failed. The CPU got to 68 degrees celcius before I noticed that WIndows XP had one of those "do you want to send an error report" dialogue boxes, and that fancontrol wasn't working at all. I had CHC set to dynamic switching and it was at 1.7 GHz @ 1.004 volts with firefox 1.5 taking 100% of the CPU (firefox only had one blank page open, strangely enough). I restarted fancontrol and all worked. I've been running the computer for days and sleeping it a lot, so that may have contributed to the cause. I hope 68 degrees is not too hot.
Here is the fancontrol.log report...
[12/31/2005 1:24:11 PM] Warning: Can't read Status (possible conflict with other software)
[12/31/2005 1:24:25 PM] Fan: 0x03 / Highest: 50°C (50 41 29 45 28 n/a 18 n/a 0 0 0 0)
[12/31/2005 1:24:25 PM] Smart: Set fan control to 0x00, Result: COULD NOT SET FAN STATE!!!!
[12/31/2005 1:34:11 PM] Current Config:
[12/31/2005 1:34:11 PM] Active= 2, Cycle= 10, FanBeep= 0 0, MaxReadErrors= 10
[12/31/2005 1:34:11 PM] IconLevels= 50 55 60, IgnoreSensors= XXX,YYY,ZZZ
[12/31/2005 1:34:11 PM] Levels= 51°C -> 0, 53°C -> 3, 55°C -> 4, 60°C -> 7, 70°C -> 0x80
Also, when I watch movies the fancontrol does a loud beep when the fan turns on and off, even thougt I have FanBeep=0 0.
All the best!
Aris
Posted: Sat Dec 31, 2005 3:32 pm
by christopher_wolf
Nope; 68 Degrees isn't too hot, rather in the upper limits of the operating range of the CPU. 90 Degrees is the throttle down and warning temperature and 100 Degrees is the critical shut off temperature.

Posted: Mon Jan 23, 2006 9:57 pm
by namezk
this warning is being written to the system event log more than 40 times every second..
\Device\ACPIEC: The embedded controller (EC) hardware returned data when none was requested. This may indicate that the BIOS is incorectly trying to access the EC without syncronizing with the OS. The data is being ignored.
Posted: Tue Jan 24, 2006 1:55 am
by christopher_wolf
Well, it is unexpected to the Windows handler because there was no query sent from the windows handler to the EC to pair up with the data that the EC indicated was returned due to a query sent through the WinIO framework. I don't know if there is another way to do it; there might be a --noverbose option somewhere in the system logger or for the Microsoft ACPI, but I am not sure. I will take a look and see if I can find anything like that.

Posted: Tue Jan 24, 2006 5:48 pm
by Bols
Without having any knowledge on the subject, it seems like using WMI or writing a device driver (which can probably access the ACPI thermal zones directly) seems the only alternatives, as the windows ACPI EC driver will then be informed what is going on.
NHC does not trigger the error, yet does not require a driver to be installed, so my guess is that it uses WMI to read CPU temperature. If anybody has better knowledge or options, please share.
I also believe that only the CPU temperature will be accessible through WMI. However, that should be "good enough" to provide reasonably safe fan control (During heavy use, the CPU is usually the hottest component, or just a few degrees below the GPU.).
BTW,
http://winhlp.com/WxACPIEC.htm provides some background and hacks for making the symptoms disappear (replacing the ACPI EC logger in the binary file). No fix for the actual problem, though.
- Trond
Posted: Tue Jan 24, 2006 7:34 pm
by christopher_wolf
Good idea; right now, the access is handled through the WinIO driver which, I think, is outside the realm of WMI. NHC uses .NET 2.0 so it is probably synchronized with the logger...Without a low level log of what events are generated by NHC, TP FCU, and the Event Logger, there is no real way to know how it is being handled. I would tend towards something like NHC being able to have synchronous access via the .NET 2.0 Framework and not triggering an unexpected return that gets logged.
This is just a topical issue, right? I haven't seen any derogatory effects of whatever triggered the messages in the log. The only case where I can say that it has an actual effect is where you try to use the fan Control Utility together with NHC; which casues a contention for synchronous control of the EC.

Posted: Wed Jan 25, 2006 6:45 am
by Bols
Yes, the WinIO/portIO approach is to blame for the errors, as they probably circumvent the whole windows HAL (or whatever would be the right term for the ACPI devices).
I just tried the generally accepted WMI access to msacpi_thermalzonetemperature, but this seems to give a constant CurrentTemperature of 32 degrees...which is definitely wrong. I also installed Almico Speedfan (NOT the same as the T4xSpeedFan), which obviously uses the same WMI approach, because it reads the same bogus temperature.
NHC obviously does something else... According to the NHC documentation it tries to read temperatures off both SMBUS and System ACPI. I tried to decompile the NHC application to see what it is doing (or even better, insert support for the Thinkpad fan control into NHC itself), but I've never tried this for .NET applications before, and there is some sort of redirection which stops direct decompile. Possibly easy to circumvent for someone who has knowledge of .NET.
Posted: Sun Jan 29, 2006 2:16 pm
by sugo
Ok I gave up. I hacked the acpiec.sys as descirbed. Now no more acpiec warning message in event log. HDD can happily spin down after idle for 3 minutes too.
Few other issues I enountered ...
When the user logs out, fan control isn't being returned to BIOS mode. Adding code to listen to WM_ENDSESSION fixed this.
InitializeWinIo can return false depending on moon phase of the moment. It causes fancontrol.exe to error exit at startup. I had to add code so that it tries 5 times and 3 seconds between each try. I wonder if it has to do with starting RMClock at about the same time.
StartMinimized = 0 still starts as minimized. Not a big deal but easily fixed.
Posted: Sat Feb 11, 2006 3:11 am
by geoffrey
sugo, are you able to make your fixes available, or are they too "low level" for general use?
Posted: Sat Feb 11, 2006 10:58 am
by ams999
Ok I gave up. I hacked the acpiec.sys as described. Now no more acpiec warning message in event log. HDD can happily spin down after idle for 3 minutes too.
I tried the hack as described on the site but got problems. During reboots my Thinkpad took breaks of two or three minutes and then gave the message "Fingerprint reader not ready". As soon as I reverted back to the normal acpiec.sys, the error went away. Tried twice, doesn't seem to work for me.

Posted: Sun Feb 12, 2006 4:44 pm
by sugo
geoffrey wrote:sugo, are you able to make your fixes available, or are they too "low level" for general use?
If anyone is interested, PM me email address and I can send it.
Posted: Sun Feb 12, 2006 4:45 pm
by sugo
ams999 wrote:
I tried the hack as described on the site but got problems. During reboots my Thinkpad took breaks of two or three minutes and then gave the message "Fingerprint reader not ready".
Sorry can't comment on that one. My T42 doesn't have a fingerprint reader.
Posted: Sun Feb 12, 2006 5:46 pm
by christopher_wolf
ams999; I don't know for sure, but this could be Windows or IBM logmon.exe trying to reload the non-modified version of acpiec.sys. Hence you get a 2-3 minute wait and the FPR may be affected. Have you tried it without the logmon process running? It usually comes on during the logon stage of th eboot process.
Posted: Mon Feb 13, 2006 6:36 am
by ams999
christopher_wolf wrote:ams999; I don't know for sure, but this could be Windows or IBM logmon.exe trying to reload the non-modified version of acpiec.sys. Hence you get a 2-3 minute wait and the FPR may be affected. Have you tried it without the logmon process running? It usually comes on during the logon stage of th eboot process.
Thanks for the suggestion! However, I don't think that logmon.exe is to blame as it's not even on my HDD. Don't know what has caused this delay but as acpiec warnings don't seem to be the only reason why the HDD doesn't spin down (last ones were four days ago, so other processes are to blame, too), I guess I'll pass on that hack.
Cheers, ams
not sure if it is a bug
Posted: Mon Feb 13, 2006 1:25 pm
by nikemen
So, I have been happilly using the tool a few days,
the only strange behaviour that I encounter is the following.
sometimes, the CPU temp on my T41 runs at 48%, my threshold is at 47%.
So, I open up the tempcontroll program, and look at the temps, the HIGH one is the CPU at 48%. So, I click on Smart Fan control, and IMMEDIATLY the temp jumps down to 41 or something.?
How is this possible, is the temp controll software reading differant sensors. I mean the CPU temp goes from 48 to 41 just by clicking on the SMART FAN control switch. The lt continues to feel hot on my lap, but it cannot switch down that fast.
thoughts
Posted: Tue Feb 21, 2006 1:55 pm
by nikemen
anyone have thoughts why the temp jump, same thing still happens.