Known Problems

With the current version (3.20.01) the PSD and related software works well and reliably on almost all systems. Some systems from certain vendors may still have problems, and a few unique and unusual systems may have issues, but for most users, the PSD and related software will work reliably without any tweaking, and without experimenting with different switches.

This page lists the known problems that may affect many users. Problems which only affect 1 or 2 unique systems are not listed here. Since these are already known problems, you do not need to open a ticket or report any of the problems listed on this page.

Problematic Vendors

Systems from Acer and Packard Bell are known to have serious compatibility problems and may not work properly. Systems from Dell are also problematic, but usually can be made to work. Systems based on an NVIDIA chipset have some minor issues but usually work very well and the remaining issues usually do not affect normal operation. Solutions for the remaining NVIDIA issues are being worked on and will likely be completely resolved in future releases.

Suspend / Resume

Suspend / Resume only works on a very small number of systems. If Suspend / Resume works for you, consider yourself among the few lucky ones. If it does not work for you, please wait for more progress to be made and try a later version. Please do not report problems with Suspend / Resume at this time.

JFS boot disks

Starting with version 3.20.01, a significant defect was fixed that affects many things including the way the system operates during the early part of the boot process. A peculiarity in the way the JFS boot loader works makes booting from JFS disks much slower. We are investigating a way to correct this problem. If you have a JFS boot disk and experience this slowness, you can use the /VW switch as a workaround until a fix is found for booting from JFS disks. Booting from HPFS disks is not significantly affected. Other ways to speed up the boot process are:

• Make sure you are using the retail version of the PSD.
• Do not use the ALT-F2 function or the ALT-F4 function.
• Don't load basedevs that you don't need. (Possible examples: PRINT01.SYS, IBM1FLPY.SYS, APM.ADD)

There is also the possibility that booting from a JFS boot disk may fail completely, or that certain other devices (such as the keyboard or mouse) may malfunction.

Spurious interrupts with certain motherboards which use an NVIDIA chipset

Some motherboards which use an NVIDIA chipset will generate spurious interrupts in Mode 1 (/VW mode), usually when the desktop starts. These interrupts occur in an unusual, unpredictable way and cause problems for both the kernel and the PSD. There currently is no solution to this problem. You cannot use the /VW switch on these motherboards until a fix for this problem is found.

SCSI drivers

While this is not an ACPI.PSD problem, I am listing it here because the PSD can reconfigure the system in a way that the drivers don't like.

It appears that most SCSI drivers have one or both of 2 problems.

1. Some SCSI drivers cannot handle interrupt numbers greater than 15.
2. Some SCSI drivers cannot handle the interrupt being changed from what the BIOS has set it to, regardless of whether or not it is greater than 15.

Both of these problems can be handled by using the /VW switch.

Previous Problems That Have Been Fixed

Power Off

NOTE: This problem has been resolved with the latest release of xworkplace / eCenter.

There is a known problem with almost all utilities that power off your system, including the xworkplace eComStation extended shutdown. This is not an ACPI.PSD problem.

The problem occurs when these utilities shut down the file systems before the power off routine has been paged into memory. When the utility calls the routine to power off the system, the kernel can't page it into memory because the file systems have been stopped. This is not a defect in ACPI.PSD or related software and cannot be fixed in the any of the ACPI software because the ACPI software does not get control at the appropriate time. It must be fixed in the power off utility.

Because of the nature of this defect, power off utilities with the defect may have randomly worked in the past because the power off routine may or may not have been in memory for some other reason. If things move around in memory, or some other program causes the routine to get paged in, the power off may have worked. The only way to reliably fix the defect is to fix the power off utility.

You can test the power off functionality of ACPI by itself by opening a command window and typing the following command:

acpistat poweroff

This command properly makes sure the power off routine is in memory before stopping the file systems. Make sure you are using the latest version of acpistat.exe.

If acpistat poweroff successfully powers off your system, then there is nothing wrong with any of the ACPI software. Do not report this as a problem with ACPI. Instead report the problem to the appropriate place for your shutdown utility (xworkplace, for example).

Systems with ACPI from Award

NOTE: This problem is fixed in version 3.20.01 or later.

There is a known problem with the ACPI provided by Award. These systems typically won't boot. The boot hangs with the boot logo on the screen.

You can determine if your BIOS has this ACPI in it by opening a command window and typing the following command:

iasl -g

This command will work whether or not ACPI.PSD is installed. The command will output a bunch of lines to the screen which will look something like this:

ACPI: RSDP F8CA0 14 (v0 VIAK8M)
ACPI: RSDT 7FFF3040 2C (v1 VIAK8M AWRDACPI 42302E31 AWRD 0)
ACPI: FACP 7FFF30C0 74 (v1 VIAK8M AWRDACPI 42302E31 AWRD 0)
ACPI: DSDT 7FFF3180 5139 (v1 VIAK8M AWRDACPI 1000 MSFT 100000E)
ACPI: FACS 7FFF0000 40
ACPI: APIC 7FFF8300 5A (v1 VIAK8M AWRDACPI 42302E31 AWRD 0)

If the line which starts with "ACPI: DSDT" has the string "AWRDACPI" in it, then your system has the Award ACPI in it. If your system has the Award ACPI in it, then you do not need to open a ticket. I already know about the problem and I am working on an fix for it.

The iasl -g command also writes a few files to the current directory which are unneeded and you can delete them.

Immediate suspend due to misbehaving SLPB device

Some systems enter suspend immediately after AcpiDaemon is started. This is due to a misbehaving SLPB device which generates repeating suspend requests.

NOTE: In version 3.19.16 and later, a workaround was implemented to ignore SLPB events if one occurs within 10 seconds of starting AcpiDaemon.exe. The SLPB events are still generated by the hardware every 2 seconds, but they are simply ignored. If AcpiDaemon logging is enabled, the log file could grow very large logging these events. An actual fix is still being investigated.