[coldkiss]

What going on with my Windows 2000 pro install with this new Athlon X2 3800+ on an MSI K8N Neo2 motherboard? Check out these temps with the bundled heatsink:

Bios temp = 40c
Win2k idle temp = 54c
Win2k load temp = 54c
WinXP idle temp = 34c
WinXP load temp = 53c

This is on fresh installs of both OS' using the ACPI multiprocessor HAL with the latest windows updates, drivers and BIOS. I use WinXP only for work and Win2k most often for gaming and web surfing so its hot heatsink ways are a little worrying.

I've tried switching to the ACPI uniprocessor HAL and that makes the temps drop down to 34c idle but of course that's with only one core active so its not much use with an X2. I wonder if the C1 HLT state is enabled in the OS when both cores are being used... Any ideas as to what could be causing this wierd behaviour?

[I_Broke_My_MHZ]

It might be an issue with the drivers.

[Oleg_II]

First version of Rollup for Windows 2000 had a bug that resulted hot temperature. Was it fixed in a new version 2 relize?

Try not applying Windows2000-KB891861-v2-x86-ENU.EXE

[Aegis]

It may be that Windows 2000 doesn't support lower power usage modes (C4 or C5?). Dunno much about processor power modes though.

[coldkiss]

Thank you for the replies and suggestions - I've managed to fix my system now, or at least find a workaround. I had a look at the different hardware driers I installed but it was Oleg_II's suggestion that uncovered the source of the problem.

It seems taht the latest Win2k update rollup (KB891861) both V1 and V2 may have a bug in the new "hal.dll" it installs for AMD X2 dual-core processors and perhaps also P4 hyperthreading or other SMP CPU setups. The original filename for this Hardware Abstraction Layer version is "halmacpi.dll" which is the ACPI Multiprocessor PC HAL. The Win2k SP4 version is 5.00.2195.6691 and KB891861 updates this to 5.00.2195.7006 - which exhibits the temperature bug with SMP systems.

I looked up the \WinNT\System32\$NtUpdateRollupPackUninstall$\ folder and found the backup SP4 version and then replaced the updated "hal.dll" file with this backup version and now the temps are fine and in line with the WinXP installation on my dual-boot system (33c idle).

This temperature problem was driving me crazy with puzzlement so many thanks to you all for your input and especially to Oleg_II!

[rChaz]

coldkiss, on Oct 31 2005, 03:19 AM, said:

...I looked up the \WinNT\System32\$NtUpdateRollupPackUninstall$\ folder and found the backup SP4 version and then replaced the updated "hal.dll" file with this backup version and now the temps are fine and in line with the WinXP installation on my dual-boot system (33c idle)...

coldkiss,
This issue also drove me nuts tracking down, but I found a good solution in an obscure reference posted on a German site mentioning this problem. They mostly suggested the hall.dll restore, but one poster mentioned the individual patch where MS originally updated the hal.dll - prior to the rollup (MS KB 835730).

KB 835730 basically mentioned a symptom that a Win2k system using HyperThreading Technology (no mention specifically of multiprocessors) may experience the computer not correctly entering the C3 power-saving state when idle. It then listed the hotfix (new hal.dll - v5.0.2195.6988 vs the newer rollup v5.0.2195.7006). To take effect, the hotfix has to be manually activated with one of two options:

1) Add the /usepmtimer switch to the Windows 2000 boot line of boot.ini

OR

2) add the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\HAL dword key named 14140000FFFFFFFF with a hex value of 00000010.

I was skeptical, but figured I'd give it a shot before resorting to restoring the earlier hal.dll version - since who knows what other security or other useful changes may be in the latest hal.dll. I used the registry activation method rather than the boot.ini switch, then I rebooted and watched as the CPU temperature cooled to normal again.

Anyway, use one of the hotfix activation methods mentioned in KB 835730 - it works!

Microsoft probably just forgot to add the registry patch in the Rollup required for multiprocessor/hyperthreading systems and the newer hal.dll.

[cluberti]

No, there's no mistake. Windows 2000 does not have the capability to understand how hyperthreading works, and thus sees a HT processor as two logical processors. Obviously the HT logical processor is not a real processor, and addressing it as such can cause the processor to run much hotter than it normally would - and thus we usually suggest that one disable hyperthreading on Windows 2000.

Also, adding those registry keys or a boot.ini switch to every machine touched by the rollup would actually be detrimental to those people who don't have dual-core or hyperthreaded processors, which is at this point likely 99% of the Windows 2000 user base. This power behavior is likely to occur with dual-core processors at this point now, as Windows 2000 is treating each as a real processor die, and causing temperatures to rise due to the nature of two cores being accessed on only one physical die.

Since Windows 2000 is only in critical patch state at this point in it's life, I doubt that something as monumental as a hal.dll rewrite will occur that makes it behave more like Windows XP and Windows 2003 with respect to these processors (they understand hyperthreading, and to a lesser extent dual core).

That's why those switches and reg hacks exist - it's an easy fix, and to be honest there aren't many people who would actually need them - most people buy their OS with their PC, and Windows 2000 never shipped (at least by default) on a dual-core or hyperthreaded machine.

This post has been edited by cluberti: 10 November 2005 - 05:49 PM

[rChaz]

cluberti, on Nov 10 2005, 06:44 PM, said:

No, there's no mistake. Windows 2000 does not have the capability to understand how hyperthreading works, and thus sees a HT processor as two logical processors. Obviously the HT logical processor is not a real processor, and addressing it as such can cause the processor to run much hotter than it normally would - and thus we usually suggest that one disable hyperthreading on Windows 2000...

I'm kind of surprised that the Rollup wouldn't be able to determine a SMP ACPI machine (mine has two processors - it's not a dual-core or hyperthreaded.) But if a SMP status actually can't be determined, I certainly understand why a reg key/boot.ini wouldn't be made to all machines. Sure would be nice to make a note of it for us poor minority that are adversely impacted without the reg or boot.ini mod. It's an easy fix only if the information is readily available; it took a lot of digging to find this solution. I consider it a mistake to not provide any notice in this situation, even with only a small percentage of systems impacted. SMP is a small percentage, but it's certainly not an unexpected configuration.

[cluberti]

That I can't speak to. I can honestly say that I haven't seen any support requests recently for this hotfix, so either people aren't aware of the heat issue, or it just isn't affecting many SMP users and is only triggered in specific situations with specific hardware types.

[mjc]

rChaz, on Nov 10 2005, 07:30 PM, said:

cluberti, on Nov 10 2005, 06:44 PM, said:

No, there's no mistake. Windows 2000 does not have the capability to understand how hyperthreading works, and thus sees a HT processor as two logical processors. Obviously the HT logical processor is not a real processor, and addressing it as such can cause the processor to run much hotter than it normally would - and thus we usually suggest that one disable hyperthreading on Windows 2000...

I'm kind of surprised that the Rollup wouldn't be able to determine a SMP ACPI machine (mine has two processors - it's not a dual-core or hyperthreaded.) But if a SMP status actually can't be determined, I certainly understand why a reg key/boot.ini wouldn't be made to all machines. Sure would be nice to make a note of it for us poor minority that are adversely impacted without the reg or boot.ini mod. It's an easy fix only if the information is readily available; it took a lot of digging to find this solution. I consider it a mistake to not provide any notice in this situation, even with only a small percentage of systems impacted. SMP is a small percentage, but it's certainly not an unexpected configuration.

Windows 2000 can detect mroe than one CPU, but it sees it as two separate CPUs. There is further information in the ACPI table to determine physical vs. logical CPUs. Basically:

Uniprocessor: One Physical, One Logical CPU.
Multiprocessor: Two Physical, Two Logical CPUs.
Multithreaded(HT): One Physical, Two Logical CPUs.

Hyperthreading simply allows more than one thread to run on the same CPU at the same time. As you can see, an operating system and application must be specifically designed to take advantage of this layout. Thread A and Thread B must not utilize the same resources at the same time or they will be in contentention for the same resources the same way that they would be if it were only one physical CPU.

Windows 2000 cannot use this additional information to make intelligent decisions as to where to place which threads and as such simply treats the second logical CPU as a physical one, thus degrading theoretical performance.

http://www.amd.com/us-en/Processors/Techni...71_9706,00.html has a utility that may be useful for determining which state your CPU is in.

AMD Power Monitor - This application is used to monitor the current frequency, voltage, utilization, and power savings of each core of each processor in a system. This application also has a system tray icon that can be used to view and select power schemes on the system. The system tray icon will show the average utilization of every core on the system.

also, check out the driver:

AMD Athlon™ 64 Processor Cool'n'Quiet Software for Windows ME and Windows 2000, Version 1.0.8.1 - AMD Cool'n'Quiet! Technology allows the system to dynamically and automatically select the CPU speed, Voltage and Power combination that match the instantaneous user perfomance need. These changes can happen as often as 30 times per second. Note: This driver is for Desktop Athlon 64 systems only.

This post has been edited by mjc: 11 November 2005 - 01:57 PM

[FDC]

If MS isn't willing to patch the dll, the least they can do is publish a separate KB article about this issue. Lack of support requests notwithstanding, I personally know lots of people who're using HT cpus with Win2K. I'd venture a guess and say many if not most of them have seen the problem but decided to just live with it.

The registry edit lowered my idle temps from 52C to back where they were before the Rollup was applied: 39C. That's quite a difference.

[cluberti]

I would strongly suggest anyone seeing this issue contact Microsoft with the problem, otherwise it will likely not get addressed publicly. It takes either a volume of support requests for a particular issue, or a serious bug or security issue for a KB article to be created. If no one tells Microsoft this is an issue for them, Microsoft isn't going to necessarily know.

[rChaz]

rChaz, on Nov 10 2005, 05:39 PM, said:

...To take effect, the hotfix has to be manually activated with one of two options:

1) Add the /usepmtimer switch to the Windows 2000 boot line of boot.ini

OR

2) add the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\HAL dword key named 14140000FFFFFFFF with a hex value of 00000010.

Just an update regarding the above; I subsequently noticed that after returning from a Hibernate state, the registry fix 2) doesn't seem to take effect, and so the 2 CPUs burn away again while idle - until a non-hibernate boot occurs.

I gave 1) a try, but it didn't seem to work at all, so it looks like it'll be back to the older version of hal.dll. That doesn't really give me the warm & fuzzies, but at least my CPUs will cool....

[LLXX]

54°C is not above the temperature limit for the processor, I wouldn't worry about it unless the increased power consumption is showing up in your electricity costs. The CPU is designed to withstand such temperatures continuously without damage.

This post has been edited by LLXX: 31 March 2006 - 10:27 PM