System Requirements, Limitations, and Handling Problems

Your system should *always* boot and run correctly with no PSD installed. If it does not, fix those problems first before testing a PSD. Note that some systems have a BIOS that does not properly initialize all the devices in the system (Notably Acer), so some devices may not work when booting without the PSD, but your system should boot.

Your system must have valid ACPI tables in order to use this software. This software is not supported on systems without ACPI tables, and this software may not function correctly on systems with bad ACPI tables.

BIOS settings:

• If your BIOS has a "Plug n Play OS" setting, it should be set to NO.
• If your BIOS has a "hyperthreading" option, it must be disabled.

Compatible software and drivers:

• ACPI.PSD, APM.ADD, ACPI32.DLL, and AcpiDaemon.exe must all be exactly the same version as shown by the bldlevel command.
• Only IBM SMP and UNI retail kernels and loaders version 14.104a or higher are supported. Use of any other kernel or loader is not supported and may not work. Some functions may not work with the debug kernel.
• Use of the old PowerMan.exe is not supported.
• The old APM.SYS driver cannot be used with this software.
• The old VAPM.SYS driver cannot be used with this software.
• The old OS2APIC.PSD cannot be used with this software.

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 is currently an unsupported feature. 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

Because of the way that the JFS boot loader works, booting from a JFS boot disk may be slower than booting from an HPFS boot disk. This is not a defect in the PSD, but rather a characteristic of the way the JFS boot loader works. We are investigating a way to improve the performance of the JFS boot loader. If you have a JFS boot disk and the slow booting is a problem for you, you can try one or more of these suggestions to improve your booting performance:

• Make sure you are using the retail version of the PSD, not the debug version.
• Make sure you are using a retail kernel, not a debug kernel.
• 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)
• Use the /VW switch to prevent using the IO APICs.

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

The PSD can reconfigure the system in a way that the drivers don't like. This is not a defect with the PSD, but rather a defect with the SCSI drivers.

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.

Power Off

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. This problem has been resolved with the latest release of xworkplace / eCenter.

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).

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. You cannot use the suspend button on systems with this problem.

Collecting Logs

Collecting logs requires that the debug version of the PSD be installed.

If you used the Warpin package, simply re-run it and select the debug package and install it. The Warpin installer installs the debug files to a separate debug directory. The debug files will not be used unless you copy the desired files to the correct locations on your boot disk.

Double click to run the "Install Debug Files" program in the "ACPI Support" folder on your desktop that was created by the Warpin Installer. This will copy the debug files to the correct places on your boot disk.

You must reboot your system to actually begin using the debug versions

Collecting a Testlog Log

1. Install the debug version of the PSD as described in the beginning of this section.
2. If you did not install from the ACPI Warpin package, download "testlog" from ​http://www.88watts.net/software.html
3. Add the /DBGLVL=3 switch to the PSD= line in your CONFIG.SYS:
4. Reboot your system to start using the debug version of the software.
5. Use "testlog acpi" or double click the "ACPI testlog.cmd" object to produce a log. When prompted, type a short description of what the problem is.
6. Attach the ZIP file to your ticket.

Collecting a Serial Port Log

If your system does not have a serial port, or you cannot collect a serial port log, collect a video log instead as described below.

If your system won't boot, the most useful log is captured from the serial port. To capture a log from the serial port you need:

1. The debug version of the PSD installed as described in the beginning of this section.
2. A fully wired null modem cable (ie. one that supports hardware handshaking). A 3 wire cable might work OK but the system will boot very slowly and you may lose some characters.
3. Another computer that will capture the serial data.
4. A terminal emulator program that will capture the serial data such as ZOC.

Then follow these steps:

1. Connect the null modem cable from the system under test to the system that will capture the serial data.
2. Start the terminal emulator program and set the baud rate of the terminal emulator to "115200,8,n,1", Enable hardware handshaking (RTS/CTS), and enable logging to a file.
3. Edit the config.sys on the system under test and change the PSD line to: PSD=ACPI.PSD /DBGLVL=3 /O1
4. Boot the system under test. When it stops close the log file on the system that was capturing the serial data and attach the log to your ticket.

Collecting a Video Log

The video log is not nearly as useful as a serial port log, but there is a possibility that it will contain some useful information. You must have version 3.19.15 or greater to produce a useful video log.

1. Install the debug version of the PSD as described at the beginning of this section.
2. Edit the config.sys on the system under test and change the PSD line to: PSD=ACPI.PSD /DBGLVL=3 /OV
3. Comment out (using REM) the APM.ADD driver and the AcpiDaemon RUN statement.
4. Rename /OS2LOGO to /OS2LOGO.sav so that the eCS logo won't be displayed. You may need to change the permissions of the file before you can rename it. You can rename this file back after you are done.
5. Boot the system under test. When it stops take a picture of the screen and attach the picture to your ticket. Do not use a flash when taking the picture of the screen.

Internal Processing Errors reported by the kernel

What if you get an error that says "The system detected an internal processing error at location" and a bunch of numbers?

One of the changes made to the PSD that is different from versions prior to 3.19.14 is that the PSD now checks for certain unsupported things and reports a failure back to the kernel. This provides for a more graceful, more reliable, and more informative failure. Previous PSDs blindly continued on and would eventually fail in more obscure, usually non-traceable ways. The kernel's method of reporting such failures is the Internal Processing Error (IPE). If you see an Internal Processing Error with the code "60004, 6009", this is the PSD reporting that it found something it couldn't handle. Unfortunately, because this part of the PSD executes so early in the boot process, there is not really a better way of informing the user of what the problem was. If your system has a serial port, you could install the debug version of the PSD, enable output to the serial port and the specific failure will be shown. Otherwise, this is a list of the possible reasons why the PSD might report a failure back to the kernel:

• A failure to allocate required memory. A memory error, for example.
• A bad return code from any of the ACPI initialization routines. A bad return code usually means that the ACPI on your machine is defective.
• A failure to map any the APICs. This would be caused by a bad ACPI on our machine.
• A failure to initialize any of the APICs. This would be caused by bad hardware.
• An unsupported kernel is detected, or if any of the patches to the kernel fail.

Please note that getting a "60004, 6009" IPE does NOT indicate a defect in the PSD. It indicates that something about your hardware is not supported, that your hardware is broken, or you are using an incompatible kernel or loader.