|Anonymous | Login | Signup for a new account||2019-04-22 16:10 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000314||SpeedFan||Hardware support||public||2005-07-15 17:01||2011-03-19 12:10|
|Platform||OS||Windows 2000||OS Version||SP0 & SP4|
|Target Version||Fixed in Version||4.43|
|Summary||0000314: ACPI sensors do not update after initial reading in Win2k|
|Description||On two completely different systems, one running a fresh install of Windows 2000 and the other running a fully up-to-date installation (SP4, 5.00.2195), Speedfan will only report a single temperature value via ACPI until the system is rebooted. |
|Steps To Reproduce||Watch an ACPI sensor.|
|Additional Information||The fresh install is on a system I just built out of relatively new hardware; the motherboard reports the CPU temperature via both ACPI and one of the Winbond chips (I don't have access to that machine at the second to get the details), and while the Winbond-reported temperatures change, the ACPI-reported temperature never does.|
The SP4 install is on a laptop which has no sensors aside from ACPI, which makes the bug a lot more annoying. The laptop is a P3-based Panasonic CF-48 (motherboard version is Mk.3), and I'm attaching Speedfan's debug.nfo output for it.
The incorrect value survives a hibernate/restart, even if Speedfan isn't running when the system is shut down for hibernate mode, but a normal reboot will yield a new value (which won't ever change until another reboot.) I know that the temperature reported via ACPI is updated fine and changes frequently, because the laptop is booted into Linux most of the time where ACPI works fine.
From the bits and pieces I've gathered, I guess that Speedfan always accesses the ACPI data via WMI, which I unfortunately know nothing about; however, it appears that the laptop (at least) doesn't generate an interrupt whenever the temperature changes. I'm not sure whether an interrupt is supposed to be generated every time the temperature changes or only when the temperature reaches a trip point, but supposing it's the former--perhaps there's a way to force windows to re-poll the ACPI data, and perhaps that's necessary on systems like mine.
Happy to provide more info--not sure whether or not the 'send info' thingie in Speedfan sends anything different than the debug info, so I didn't try doing that yet.
|Tags||No tags attached.|
|Video Card Model|
|Attached Files||debug.nfo [^] (9,405 bytes) 2005-07-15 17:01|
I'm heavily investigating ACPI. One of the most important ACPI engineers at Microsoft told me that ACPI temperature readings are often broken. What I think is that it is updated only on specific occasions. I read that power status changes might force the temperature to be read again.
I changed the severity to FEATURE as it is not a failure on SpeedFan's side. SpeedFan is actually showing the data made available by the OS and the ACPI BIOS. Anyway: I'm looking for a tweak to force such an update.
edited on: 2005-07-19 21:10
FWIW, power status changes and lid button events (both of which generate ACPI interrupts) don't cause any change in the value Speedfan displays; restarting Speedfan has no impact, either, as expected.
Also FWIW, I know for certain that the BIOS will provide values on demand (if polled), since I can easily see temperature vary with CPU usage in a different OS. The main problem, I guess, is with the WMI's interface to ACPI: if the BIOS is supposed to have a way to notify the OS of temperature changes, but in fact almost none of them do, real world syndrome should set in and at least offer some workaround to the programmer.
I have the same problem (almost posted it as a new bug...) on my Sony Vaio notebook (running Win XP SP2, SpeedFan 4.25). It reports one ACPI temperature, and it never changes from the initial value.
(it also reports a hd0 temperature, which is read correctly)
However, that initial value seems to be set correctly when I start SpeedFan:
If I start SpeedFan when my cpu usage is at 100%, it's a higher temperature
If I start SpeedFan when my cpu is idle, it's a lower temperature.
Also, I have found a program that correctly reads and updates the temperature: mobilemeter (English readme at http://dssc3031.ece.cmu.edu/~tamaru/mobilemeter/mobilemeterreadme-e.htm [^])
This implicates either it IS a SpeedFan error, or there exists a workaround.
(running mobilemiter and speedfan together doesn't make SpeedFan update the temperatures)
I sent you a SpeedFan report (via the info tab), and also the read acpi tables beta tool report - don't know if these are of any help...
edited on: 2006-03-30 16:22
Let me add a "me too". :(
I am running Win XP Pro SP2, and Speedfan 4.28. I have a DFI LP875P-T motherboard with a P4 "551".
The ACPI temp seems to be set only once at the startup of Speedfan, and stays fixed at that value regardless. Whereas, the CPU temp as reported by the Winbond chip various as expected (varies with CPU load).
I have downloaded the MobileMeter utility mentioned previously, and it seems to have no problems reading and updating its value for ACPI temperature. So, based on that, I am fairly sure I don't have a software, BIOS, or motherboard problem.
I have also downloaded the ACPI Explorer Test for Speedfan, and submitted the results, if that is of any help.
edited on: 2006-03-31 00:01
I downloaded the add-on MBM called ACPI Temp Probe. It apparently can run independent of MBM and has its own small window.
It shows the same ACPI temperature as Speedfan, and just like Speedfan does NOT update even though it update interval is set to 10 seconds. :(
The WMI Info reported by ACPI Temp Probe:
Ram WMI Info
Thermal Zone 0
Active Trip Point Count: 1
Critical Trip Point: 3682
Current Temperature: 3072
Instance Name: ACPI\ThermalZone\THRM_0
Passive Trip Point: 3332
Sampling Period: 60
Thermal Constant1: 4
Thermal Constant2: 3
Thermal Stamp: 6
However, MobileMeter continues to have no problems updating itself correctly showing changes in the ACPI reported temperature.
|2005-07-15 17:01||rain||New Issue|
|2005-07-15 17:01||rain||File Added: debug.nfo|
|2005-07-19 17:37||alfredo||Note Added: 0001046|
|2005-07-19 17:37||alfredo||Severity||major => feature|
|2005-07-19 17:37||alfredo||Status||assigned => acknowledged|
|2005-07-19 21:05||rain||Note Added: 0001062|
|2005-07-19 21:10||rain||Note Edited: 0001062|
|2005-08-21 01:41||alfredo||Relationship added||has duplicate 0000324|
|2005-08-30 11:41||brain99||Note Added: 0001123|
|2006-03-30 00:50||walt||Note Added: 0001597|
|2006-03-30 16:22||walt||Note Edited: 0001597|
|2006-03-30 23:59||walt||Note Added: 0001604|
|2006-03-31 00:00||walt||Note Edited: 0001604|
|2006-03-31 00:01||walt||Note Edited: 0001604|
|2006-03-31 00:01||walt||Note Edited: 0001604|
|2011-03-19 12:10||alfredo||Status||acknowledged => resolved|
|2011-03-19 12:10||alfredo||Resolution||open => fixed|
|2011-03-19 12:10||alfredo||Fixed in Version||=> 4.43|
| Copyright © 2000 - 2019 MantisBT Team
Time: 0.1228 seconds.|
memory usage: 8,109 KB