Long story... essence is that Sempron 3400 is back in Compaq sr1710nx (after failed X2 install), and even this is running very slow (2 hours to run 30 mins of Rosetta), and hangs frequently.

I see that under Device Manager / Computer, it shows "ACPI Multiprocessor PC".

As single core Sempron is now installed, and Win XP was installed after Sempron install, this seems wrong to me.

Can anyone confirm what should be correct entry for uniprocessor?

If wrong, pls point to instructions how I can install proper HAL for Uniprocessor.

Just trying to return Compaq to original state prior to X2 attempted install.

Thanx!

Just trying to return Compaq to original state prior to X2 attempted install.

Thanx!

Hi Penguin,

go to:

Control Panel => DEvice Manager => Computer => ACPI Multiprocessor PC => Driver => update driver => reboot

That should do it to make it a uniprocessor PC again. But I am not sure if that cures the sluggish behavior as it may not be the only cause.

Forces me to Hardware wizard / location of new driver. There are none to manually select.

Hi Penguin,

go to:

Control Panel => DEvice Manager => Computer => ACPI Multiprocessor PC => Driver => update driver => reboot

I agree, may have to go back to Compaq. One of the reasons I want to ensure that correct HAL ACPI displays in Device Manager.

That should do it to make it a uniprocessor PC again. But I am not sure if that cures the sluggish behavior as it may not be the only cause.

Unless you really care about the performance inside the OS, by which I mean the amount of time shown in red by Task Manager's performance graph when you enable "Show system time", I wouldn't bother to try to change it back.

The time(s) when the system behaves differently based on the Multi/Uniprocessor HAL is when it uses spinlocks - it's a "no operation" on a single processor, but will have "real code" when it's on a multiprocessor.

And since there's no other processor to contend with the locks, the locks will just "walk through" the code, never have to spin. A spinlock looks something like this:

void spinlock(int *lock)
{
while(*lock);
*lock = 1;
}

void spinunlock(int *lock)
{
*lock = 0;
}

If *lock is zero when you come into the lock, it won't have to loop around waiting for it to clear. [Note: The above code is slightly simplified, because you have to guarantee that there's no other processor able to write to the lock itself, and this means using some special instructions to test and set the lock in a single operation, but that's not really important for this discussion - the above code would break if another processor is also waiting for the spinlock and "wins" the race to set *lock=1 in the second line when lock is cleared by a third processor. Two processors would now think they both own the lock!]


There will be some minor differences in other places too [mainly that there is no need to "indirect" things in places that keep track of processor context], but it's REALLY difficult to get a benchmark that shows any noticable difference. One that would is probably something like SpecWeb or other "networking" benchmarks.

When it comes to Rosetta, I can guarantee that there's no difference whatsoever, since Rosetta spends less than 1% of the time it is running in places where this makes a difference.

If you don't understand the above arguments, just understand this: The difference between the uni- and multiprocessor HAL is very small for average users. There are special cases where it makes a noticable difference, but it's very unlikely that you'll ever notice any difference on your machine.

--
Mats

---

May have send pc back to Compaq for repair, its the reason I want to ensure that correct HAL ACPI displays in Device Manager when they examine it.

If you don't understand the above arguments, just understand this: The difference between the uni- and multiprocessor HAL is very small for average users. There are special cases where it makes a noticable difference, but it's very unlikely that you'll ever notice any difference on your machine.

--
Mats

did you change the acpi in the bios back to disabled/off?

If you're about to send the machine back to the manufacturer, I would make sure that any data and applications you have installed are backed up some way. If you back up everything that is of value on the machine, there should be no reason why you can't spend another 15-30 minutes going through the re-install process of the OS... That should definitely fix up the uni-/multiprocessor setting.

However, I would very much doubt that anyone would actually figure out that a uniprocessor machine is set for multiprocessor... And even if they do, it's not a reason to decline warranty work - they may wish to reset it so that you're complying with their standard setting, but I very much doubt that they can blame multiprocessor HAL for a failure on a warranty-claim... Why would they? Is the machine not under warranty if you change settings in the system? What if you change the resolution of the screen, will that also void the warranty? What if you change the background picture? It's perfectly VALID to run SMP hal on a uniprocessor system. If they query it, say that you were trying to figure out if a particular software would work on a multiprocessor HAL...

--
Mats

---

Low-end Compaq does not offer such an option in Bios.

did you change the acpi in the bios back to disabled/off?

Have tried about a half-dozen times. Only able to re-install via Compaq emergency partition. Don't have access to oem install cd.

Can I just delete the following and re-try from Compaq emergency partition?

c:windowssystem32hal.dll
c:windowssystem32ntkrnlpa.exe
c:windowssystem32ntoskrnl.exe

there should be no reason why you can't spend another 15-30 minutes going through the re-install process of the OS... That should definitely fix up the uni-/multiprocessor setting.

Quite possibly true... but I don't want to put the idea in a tech's mind that perhaps they should open the chasis and see if there is anything that looks like it might void a warranty...

However, I would very much doubt that anyone would actually figure out that a uniprocessor machine is set for multiprocessor... And even if they do, it's not a reason to decline warranty work - they may wish to reset it so that you're complying with their standard setting, but I very much doubt that they can blame multiprocessor HAL for a failure on a warranty-claim... Why would they? Is the machine not under warranty if you change settings in the system? What if you change the resolution of the screen, will that also void the warranty? What if you change the background picture? It's perfectly VALID to run SMP hal on a uniprocessor system. If they query it, say that you were trying to figure out if a particular software would work on a multiprocessor HAL...

--
Mats

You could edit the boot.ini to be able to select different hall modes an donce in the correct working one you can remove the other entries (this is often used to move between PIC and APIC hals) The ACPI APIC hal you're using should switch automatically back to ACPI uniprosessor PC..


one tic....

This page may give you more information
http://support.microsoft.com/?id=309283
HAL options after Windows XP or Windows Server 2003 Setup
should tell you how to force a reinstall of windows with a differetn hal.



another way that may work is to create another hardware profile and get it to boot to that at the start, it should then auto detect everything and you'll have a backup profile just in case

---

Team mauisun.org

by the way, you did try the normal method of going to
Device Manager -> ACPI multiprocessor PC and then using the update feature (tried selecting your own ? Advanced -> let me choose...). Since that way should work.

---

Team mauisun.org

Windows won't start (I think) if you just delete those files. The feature to change the HAL in Device Manager in XP is deliberately disabled by Microsoft - it works for previous versions of Windows but not for XP.

See troubleshoot HAL from Microsoft. Below you'll find the names of the relevant files for easier access.

You need to replace three files in the system32 folder then restart Windows. The best set of files can be found in the cab files from the XP redistributable SP2 (yes I know it's big) found at Microsoft. You can also use the files (already expanded) found in Windows/ServicePackFiles/i386 - this would be best if you have that folder and it contains the proper files.

It is still problematic to change these 3 files because they can have been updated by regular Windows updates. If you get Windows running after you change these 3 files it is best to manually run the Windows update process to see if MS will detect if these 3 files need further updating.

The article refers to Win2000 but it should apply equally to XP.
Folder winnt/system32 is changed to Windows/system32 for XP.

You can change these filenames from the Recovery Console - at the command prompt (at least I think you can). You need to be able to run Recovery Console from a Win install CD or have installed Recovery Console into Windows. Be sure you can successfully run the Recovery Console before you begin. Windows (online) help file has more info on how to run it or install it.

To make this easier you need to find the files with your operating copy of Windows first and put the files in place in the system32 folder with a changed name such as hal.new.dll, you'll be able to find them quicker. Be sure you know how to get the files extracted/expanded out of the .cab first, either with a built-in extractor such as that in the 7-zip app or by using the Windows provided extract/expand utility. I mention this because it is possible to end up with an un-expanded copy of the file. Check the extracted files with File|Properties in Explorer - good files will show the version info.

Just to be safe, copy your existing 3 files and keep them in case this process fails.

An alternative to hunting down the files from the cab files is just to find another running version of Windows with the uniprocessor files and then just copy them (like on a floppy).

___________________________________
The following is extracted from the url above.

2. After you log on to your computer, from the %SystemRoot%System32 folder of your original Windows 2000 installation,
use the command console to copy and rename the following files as noted in the following lists.
First determine which HAL and kernel files your computer requires by using the following list of supported computer types:

NOTE: Those marked with an asterisk character are Standard computer types (non-ACPI).
(You need only one of the following!)

i386 source file: i386driver.cabhalmacpi.dll
Computer type: ACPI Multiprocessor PC
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: i386driver.cabhalaacpi.dll
Computer type: ACPI Uniprocessor PC
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: i386driver.cabhalacpi.dll
Computer type: Advanced Configuration and Power Interface (ACPI) PC
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: *i386driver.cabhalsp.dll
Computer type: Compaq SystemPro Multiprocessor or 100% Compatible
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: *i386driver.cabhalapic.dll
Computer type: MPS Uniprocessor PC
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: *i386driver.cabhalmps.dll
Computer type: MPS Multiprocessor PC
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: *i386driver.cabhal.dll
Computer type: Standard PC
Copy to this folder: winntSystem32
Rename to this file name: hal.dll

i386 source file: *i386driver.cabhalborg.dll
Computer type: SGI mp
Copy to this folder: winntSystem32
Rename to this file name: hal.dll


3. As indicated in the following table, copy all the appropriate kernel files common for your system (Uniprocessor vs. Multiprocessor)
and the appropriate HAL file based on your computer supported computer type from the Windows 2000 CD-ROM (i386driver.cab)
or installed service pack to the corresponding folder listed in the table under your original Windows 2000 installation,
and then rename them (if required) to Ntoskrnl.exe and Hal.dll, respectively.

Common Multiprocessor kernel files Copy to the following directory Rename to the following filename
---------------------------------------------------------
i386driver.cabntkrnlmp.exe winntSystem32 ntoskrnl.exe
i386driver.cabntkrpamp.exe winntSystem32 ntkrnlpa.exe
(following 4 files are the same - don't need to copy )
(i386driver.cabkernel32.dll winntSystem32 kernel32.dll )
(i386driver.cabntdll.dll winntSystem32 ntdll.dll )
(i386driver.cabwin32k.sys winntSystem32drivers win32k.sys )
(i386driver.cabwinsrv.dll winntSystem32 winsrv.dll )

Common Uniprocessor kernel files Copy to the following directory Rename to the following filename
---------------------------------------------------------
i386driver.cabntoskrnl.exe winntSystem32 ntoskrnl.exe
i386driver.cabntkrnlpa.exe winntSystem32 ntkrnlpa.exe
(following 4 files are the same - don't need to copy )
(i386driver.cabkernel32.dll winntSystem32 kernel32.dll )
(i386driver.cabntdll.dll winntSystem32 ntdll.dll )
(i386driver.cabwin32k.sys winntSystem32 win32k.sys )
(i386driver.cabwinsrv.dll )
___________________________________________________________



So, for computer type: ACPI Uniprocessor PC

i386driver.cabhalaacpi.dll -> windowsSystem32hal.dll
i386driver.cabntoskrnl.exe -> windowsSystem32 ntoskrnl.exe
i386driver.cabntkrnlpa.exe -> windowsSystem32 ntkrnlpa.exe

The additional 4 files may or may not need to match, you may need to extract them also from the SP2 cab file. This is usually unnecessary.

Good luck! I suppose you've thought about just wiping the disk and doing a full 'real' install. I don't know whether the Compaq files will permit this - I'm guessing not.

Forces me to Hardware wizard / location of new driver. There are none to manually select.

by the way, you did try the normal method of going to
Device Manager -> ACPI multiprocessor PC and then using the update feature (tried selecting your own ? Advanced -> let me choose...). Since that way should work.

I'm just gonna have to get me a "real" install cd one of these days. Those "recovery" partitions just don't seem to cut it.

Thanx for all the info.

Windows won't start (I think) if you just delete those files. The feature to change the HAL in Device Manager in XP is deliberately disabled by Microsoft - it works for previous versions of Windows but not for XP.

Good luck! I suppose you've thought about just wiping the disk and doing a full 'real' install. I don't know whether the Compaq files will permit this - I'm guessing not.

I'm just gonna have to get me a "real" install cd one of these days. Those "recovery" partitions just don't seem to cut it.

Yap that's it! I'm afraid there is no other way. Should be not such a big problem to get a normal Win XP CD.

MS or eBay?

I'm just gonna have to get me a "real" install cd one of these days. Those "recovery" partitions just don't seem to cut it.

Yap that's it! I'm afraid there is no other way. Should be not such a big problem to get a normal Win XP CD.

[quote]MS or eBay?

If you have friends with a Dell running the same version (home or pro) of XP as you, and the install key sticker for your copy of WinXP says "OEM" - then you can use a copy of your friend's Dell WinXP install cd.

---

Looked. Compaq sticker does NOT say "oem".

and the install key sticker for your copy of WinXP says "OEM" - then you can use a copy of your friend's Dell WinXP install cd.

If you look at Task Manager while trying to run a crunching program (rosetta, super pi, prime95, etc.) does it say the crunching program is getting 99% of the CPU? Is anything else getting a substantial ammount of CPU? Is the idle task getting any CPU?

If you look at Task Manager while trying to run a crunching program (rosetta, super pi, prime95, etc.) does it say the crunching program is getting 99% of the CPU? Is anything else getting a substantial ammount of CPU? Is the idle task getting any CPU?

How is ANY of this comment related to the subject discussed - and why should there be any difference in Task Manager based on which HAL is being used? The scheduler's basic principle is the same for both single- and multi-procesor version of the NT kernel, so there should be no difference as to idle-tasks CPU usage - if you run Rosetta and you get any amount of CPU usage for Idle, then one of three things have happened:
1. Rosetta is out of work.
2. Rosetta is reading/writing to some file(s).
3. Rosetta is using more memory than is available, and Windows is swapping to disk [idle gets to run when the OS is waiting for disk-data to be transferred, as there's nothing much else to do at this point - unless some other process is runnable of course].

--
Mats

---