System Requirements, Limitations, and Handling Problems
Hardware and Vendor Supplied Firmware (BIOS/UEFI/ACPI…):
- Your system must have generic, standards compliant, properly working hardware. The PSD has workarounds for, and will work on systems with minor hardware quirks. However, systems that employ major deviations from the standards may not work properly. See the Problematic Hardware and Vendors section below. In summary, AMD CPUs and chipsets are OK, Intel CPUs and chipsets are OK, Nvidia hardware is not recommended. OS/2 has always had a strict requirement for properly operating hardware, more strict than other software, and that requirement continues today.
- The Vendor Supplied Firmware (VSF) in your system must properly enumerate and setup the system devices. The PSD has workarounds for, and will work on systems with minor Vendor Supplied Firmware defects. However if certain critical pieces are missing or don’t work, you will not be able to boot, or some features won’t work after booting.
- Your system must have valid ACPI tables that properly describe the hardware. The PSD has workarounds for some common minor ACPI defects, so systems with these minor ACPI defects will work. Systems with seriously broken ACPI tables will not work properly.
- If any devices uses an interrupt higher than 60 and those devices don’t use MSI, those devices will not work and may prevent the system from booting. The PSD will display the message “Warning some Devices could not be assigned IRQ (out of range)” if any devices use an unsupported interrupt. If your system will run using the /VW switch, you can use that to prevent the APIC interrupts from being used.
Vendor Supplied Firmware settings:
- If your system has a “Plug n Play OS” setting, it should be set to NO.
- If your system has a “hyperthreading” option, it must be disabled.
Compatible software and drivers:
- The Warpin installer for the ACPI Driver Package will verify compatible OS and Drivers.
- ACPI.PSD, APM.ADD, ACPI32.DLL, and AcpiDaemon.exe must all be exactly the same version as shown by the bldlevel command.
- This software will run with full functionality, with all enhanced features, on the following kernels:
- Arca Noae 14.201 SMP Retail
- Arca Noae 14.104b SMP Debug
The software will run on the following SMP kernels, but some advanced features may not be available. Currently, the only feature not available on the following SMP kernels is the ability to use interrupt numbers greater than 31. See the Number of Interrupts, Kernel Versions section below for more details.
- Arca Noae 14.200 SMP Retail
- Arca Noae 14.104a SMP Debug
- IBM 14.104a SMP Retail
- IBM 14.105 SMP Retail
- IBM 14.106 SMP Retail
The software will run on the following W4 kernels. The PSD always runs in PIC mode on W4 kernels, so none of the advanced interrupt features are available, and none of the advanced PCI configuration features are available.
- IBM 14.104a W4 Retail
- IBM 14.105 W4 Retail
- IBM 14.106 W4 Retail
You must also be using either the IBM or Arca Noae loader. Other kernels not listed above, or other loaders might work but are not supported. Some functions may not work with the debug kernel. Some functions will not work with the W4 kernel. Use of QSINIT, for example, is not supported and while it may work for one version, there is no guarantee that it will continue to work with future versions.
- 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.
If you are using the following drivers, make sure you have the latest version. Some very old versions may cause problems.
The PSD is an ACPI based driver. This means that it relies on the information provided by the ACPI in your system and can only do things described by and allowed by the ACPI in your system. If any of the ACPI information is incorrect or any of the ACPI functions don’t work, then these features won’t work on your system with this PSD. This PSD probably does not contain workarounds for defects unique to certain hardware/ACPI/VSF that may be present in other software like Windows or Linux.
Number of Interrupts, Kernel Versions
Earlier versions of the PSD (3.23.03-3.23.05) enabled the use of interrupts greater than 31. Later it was discovered that the kernel cannot handle these higher interrupts and will trap in some situations. Therefore, starting with version 3.23.06 the PSD will detect whether or not the kernel can support interrupts greater than 31 and will only enable them if the kernel supports them. Currently the only kernels that support interrupts greater than 31 are the Arca Noae 14.201 SMP retail kernel and the Arca Noae 14.104b SMP debug kernel. These kernels are only available with ArcaOS and are only licensed for use with ArcaOS.
Problematic Hardware and Vendors
- Systems from Acer are known to have serious compatibility problems and may not work properly. Acer hardware is not recommended.
- Some motherboards that use an Nvidia chipset have serious compatibility problems and usually will not work properly. Nvidia hardware is not recommended.
- Systems from Packard Bell have been reported to not work properly.
- A few systems from Dell have issues, but usually can be made to work.
Virtual Wire Mode
Many people think that if things don’t go quite right, try adding /VW to the PSD command line. While this can be a useful diagnostic tool, usually it is not recommended to use /VW without a valid reason. Using the /VW switch is and always has been a downgrade. It limits the PSD’s ability to configure the system in a modern configuration.
These are the only reasons why you would need to use the /VW switch:
- If you are using a old driver that can’t handle interrupt numbers higher than 15 and you cannot upgrade that driver. (SCSI drivers, for example.)
- If you have hardware that has malfunctioning APIC hardware. This may be the case with some very old systems.
- If your system has an excessive number of IOAPICs which in turn results in an excessive number of interrupts. If your system has more than 60 interrupts, *and* any device you need to use uses an interrupt higher than 60, *and* that device and driver doesn’t use MSI, then you need to use /VW to limit the system to the old configuration style.
Beware that many modern motherboards do not have the old style PIC hardware wired up completely, so /VW (or /PIC for that matter) won’t work at all on those systems. In addition, even if /VW does work it can cause system instability. Running a system with /VW is not recommended. Avoid using /VW unless absolutely necessary.
By default, the PSD reconfigures the system to use modern, advanced interrupts. Most older SCSI drivers can’t handle this. This is not a defect with the PSD, but rather a limitation in the old SCSI drivers.
It appears that most SCSI drivers have one or both of 2 problems.
- Some SCSI drivers cannot handle interrupt numbers greater than 15.
- Some SCSI drivers cannot handle the interrupt being changed from what the Vendor Supplied Firmware 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. This downgrades the PSD to configure the system using old style interrupts. Warning: Modern hardware may not work in Virtual Wire Mode (/VW) and /VW can cause system instability.
Suspend / Resume
Suspend and Resume is not officially supported at this time. This means that it may or may not work for you and if it does work, you may or may not have issues with the system when resumed.
Suspend and Resume should work reasonably well, if all all of the following conditions are met:
- All of your device drivers must properly support suspend and resume
- Your system’s ACPI and your system’s Vendor Supplied Firmware (VSF) must properly implement the S3 sleep state and be able to wake up from it.
- Only attempt to suspend your system when it is completely idle. No I/O should be active when you suspend
Current experience shows that only about 20% of systems are capable of suspend and resume. If you want to try suspend and resume read the suspend and resume section of the documentation first. If suspend and resume doesn’t work on your system, first make sure you have the latest versions of all your device drivers. If it still won’t suspend or resume, try removing questionable drivers until you find the one causing the problem. If you can’t find a driver that is causing the problem, your system may not be able to do an ACPI driven suspend and resume. If you find a specific problem that you can identify (including a specific driver you know is causing a problem), please open a ticket. There are no logs that can help debug suspend and resume problems so we are unable to provide assistance for “it doesn’t work” type of tickets.
JFS boot disks
Because of the way that the JFS boot loader works, and the nature of the JFS file system, booting from a JFS boot disk may be slower than booting from an HPFS boot disk. Maximum boot performance is obtained by using a small (2 GiB) HPFS boot disk, and using separate JFS partitions for all your programs and data.
Hyperthreading is not recommended.
The PSD does not know or care about hyperthreading. Therefore there is no issue about the PSD supporting or not supporting hyperthreading. It just doesn’t care. The only reason people think that the PSD has anything at all to do with hyperthreading is because hyperthreading, by definition, involves multiple CPUs, and you cannot use multiple CPUs without a PSD.
The OS/2 kernel is another matter. The scheduler in the OS/2 kernel assumes symmetrical CPUs. After all, that is what the S in SMP means. The fake CPUs created by hyperthreading are most definitely not symmetrical. This will negatively affect performance.
There are also other differences with the fake CPUs that can negatively affect system stability. If you use hyperthreading you may experience the following symptoms. Your results may vary depending on the specific hardware implementation in your system.
- Slow performance
- System stability issues
- Strange CPU usage
- Failure to boot
- Random system hangs, or failures.
If you have strange problems with your system, try turning off hyperthreading in the Vendor Supplied Firmware setup. Systems running with hyperthreading enabled are not supported. We are unable to provide assistance for problems caused by using hyperthreading.
RESOLVED in updated xworkplace / eCenter.
There is a known problem with almost all utilities that power off your system, including the xworkplace 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 Driver software because the ACPI Driver 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:
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 that indicates a problem with the power off utility you are using. Do not report this as a problem here. Instead report the problem to the appropriate place for your shutdown utility (xworkplace, for example). If acpistat poweroff does not successfully power off your system, then there is probably a problem with the ACPI in your system.
Immediate suspend due to misbehaving SLPB (sleep button) 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 detailed logs requires that the debug version of the PSD be installed.
To install the debug version of the PSD, simply re-run the Warpin package and select the debug package and install it.
You must reboot your system to actually begin using the debug versions.
To stop using the debug version of the PSD and re-install the normal retail version, simply re-run the Warpin package and re-install it but do not select the debug package for installation.
Collecting a Testlog Log
- Download the latest TestLog program from here: Get TestLog
- Install the debug version of the PSD as described in the beginning of this section.
- Make sure there are no switches on the PSD= line in your CONFIG.SYS unless the developer has specifically requested them.
- Reboot your system to start using the debug version of the software.
- Open a command prompt and use “testlog acpi” to produce a log. When prompted, type a short description of what the problem is. Do not run the testlog program more than once. The debug data is read from the PSD and cleared each time testlog is run.
- Attach the generated log 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:
- The debug version of the PSD installed as described in the beginning of this section.
- 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.
- Another computer that will capture the serial data.
- A terminal emulator program that will capture the serial data such as ZOC.
Then follow these steps:
- Connect the null modem cable from the system under test to the system that will capture the serial data.
- 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.
- Edit the config.sys on the system under test and change the PSD line to: PSD=ACPI.PSD /O1
- 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.
- Install the debug version of the PSD as described at the beginning of this section.
- Edit the config.sys on the system under test and change the PSD line to: PSD=ACPI.PSD /OV
- Comment out (using REM) the APM.ADD driver and the AcpiDaemon RUN statement.
- Rename /OS2LOGO to /OS2LOGO.sav so that the boot 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.
- 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 your 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.