System Requirements, Limitations, and Handling Problems

Requirements, limitations, and things to check if you have problems

• 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 (UEFI BIOS/Traditional BIOS/ACPI/etc.) in your system must properly enumerate and setup the PCI configuration space for all the system devices. The PSD has workarounds for, and will work on systems with minor BIOS 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 supports ACPI version 2.0 through version 6.4. 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 an interrupt (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 advanced (APIC) interrupts from being used. However, running a system with /VW is a degraded configuration and is not recommended if you can avoid it.
• Do not run a system with debug modules installed. The debug modules are slower and may not run as well as the normal modules, may have limited functionality, and are not supported for normal use. The debug modules should only be installed for diagnostic purposes and only when requested by the developer.

BIOS settings

• If your system has a “Plug n Play OS” setting, it should be set to NO.
• If your system has a “hyperthreading” or a “Simultaneous multithreading (SMT)” option, it should 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.202 SMP Retail
  • Arca Noae 14.203 SMP Retail
  • Arca Noae 14.204 SMP Retail
  • Arca Noae 14.104b SMP Debug
  • Arca Noae 14.104c 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.
  • Arca Noae 14.200 W4 Retail
  • Arca Noae 14.201 W4 Retail
  • 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 appear to work for one version, it may not continue to work with future versions.
• If you are using Uniaud, DaniS506 or Panorama, make sure you have the latest version. Some very old versions of these drivers may cause problems.
• 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.

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 may not contain workarounds for defects unique to certain hardware/ACPI/BIOS that may be present in other software like Windows or Linux.

Known Issues

Disabling the Power Manager on multi-CPU systems

Disabling the Power Manager on multi-CPU systems is not recommended and strongly discouraged. The default is enabled and the default settings are best for almost every system. When the Power Manager is changed from enabled to disabled the power manager sets the system to a normal default state which means all CPUs on, full power, and not throttled. This will make your CPU run extremely hot and can cause permanent damage.

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 and later retail kernels and the Arca Noae 14.104b SMP and later debug kernels. 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.
• Many systems from Dell have issues, but usually can be made to work.
• The Intel Sunrise Point chipset has been reported to have problems booting and to have USB problems.

Virtual Wire Mode

In some cases trying /VW can be a useful diagnostic tool. However 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. Some drivers like XHCI and NVME won’t work properly, or won’t work at all with /VW or /PIC.

SCSI drivers

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.

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. 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. Some drivers like NVME and XHCI may not  work with /VW.

Suspend / Resume

Suspend and Resume is not supported and does not work.

Hyperthreading and Simultaneous Multithreading (SMT)

Hyperthreading and Simultaneous multithreading (SMT) is not recommended. Both Hyperthreading from Intel and Simultaneous multithrading from AMD are similar and the use of the term “hyperthreading” in this document shall mean both.

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 additional CPUs created by hyperthreading are not symmetrical. Using them will negatively affect performance.

There are also other differences with the additional 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.

Hyperthreading problems were more prevalent years ago. The hyperthreading technology has improved since then. You may or may not have problems with hyperthreading on your particular system. If you have strange problems with your system, try turning off hyperthreading in the BIOS setup. Due to the problems related to hyperthreading, systems running with hyperthreading enabled are not officially supported. We are unable to provide assistance for problems caused by using hyperthreading.

Power Off

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.

Collecting Logs

Some information is available using the normal retail version of the PSD, However, collecting detailed logs requires that the debug version of the PSD be installed. Use whichever version the developer asks for. The debug version is required to produce a video log.

To use the debug PSD using the ArcaOS installer, choose “Boot with menu for own values” and on the first page select “Use debug version” under “Advanced Configuration and Power Interface (ACPI) support”. Then in the “Parameters” field you will use whatever switches are needed for the type of log capture you are using below. For example for a COM port log you might use /COM=1. For a video log you would use /OV. For a Testlog log file no switches are needed.

To install the debug version of the PSD on an installed system, simply re-run the Warpin package and select the “OS/2 ACPI Support – ACPI Debug Modules” package and install it. The debug modules are only in “Test” Warpin distributions and are not included in the retail ACPI distributions. The developer will provide a test build for debugging.

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

Collecting a Testlog Log

1. Download the latest TestLog program from here: Get TestLog
2. If instructed by the developer, install the debug version of the PSD as described in the beginning of this section.
3. Use whatever switches on the PSD= line in your CONFIG.SYS the developer has specifically requested.
4. Reboot your system.
5. 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.
6. 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:

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 /COM=1
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 essentially the serial port log redirected to the video display. It is not nearly as useful as a serial port log because much is lost when scrolling the display, 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. The video log feature may not work on all systems, but should work on most systems booted in a Traditional environment (including UEFI BIOS systems with a CSM). The video log feature is known to not work in UEFI BIOS systems when not using a CSM.

1. Install the debug version of the PSD as described at the beginning of this section. The video log feature will not work with the retail version.
2. Edit the config.sys on the system under test and change the PSD line to: PSD=ACPI.PSD /OV
3. Comment out (using REM) the APM.ADD driver and the AcpiDaemon RUN statement.
4. For installed systems, 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. When booting the installer, choose “Verbose boot” in the pre-boot menus.
5. Boot the system under test. When it stops take a picture of the screen and attach the picture to your ticket.

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?

When an error occurs that prevents the system from continuing to run, the kernel must stop the system and report the error. There are 2 mechanisms for this: the trap and the Internal Processing Error (IPE). Because some portions of the PSD execute very early in the boot process, the PSD cannot display any messages so it reports failures to the kernel using an Internal Processing Error (IPE). The kernel lumps all errors reported by the PSD into the same IPE with the code “60004, 6009”. 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. Further investigation is required to determine the cause of the IPE. If your system has a serial port, you can install the debug version of the PSD, enable output to the serial port and a specific failure will be shown. The following 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 of 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. This would be caused by trying to use an unsupported kernel or loader.
• A failure to start a secondary processor. This would be caused by bad hardware.

There could also be other reasons not enumerated here. Note that a 60004, 6009 IPE can happen for a number of different and unrelated things. The only way to know what caused your particular 60004, 6009 IPE, or if your 60004, 6009 IPE is related to a previous one, is to examine the PSD serial port output. The serial port output from PSD (possibly via the video log) is the only way to determine the cause of a 60004, 6009 IPE. Information about an IPE is not contained in a testlog log file. It is also important to note that getting a 60004, 6009 IPE does NOT indicate a defect in the PSD. It indicates that something about your hardware does not meet the minimum requirements for the PSD to function, that your hardware is not working properly, or you are using an incompatible kernel or loader.

Some things you can check if you get a 60004,6009 IPE are: Processor overheating, Processor overclocking, Power supply voltages, Power supply noise, Power supply capacity, Power cabling, Processor heat sink, Motherboard power capacitors.

If your system has a multi-core processor you can try adding /MAXCPU=1 to the PSD command line in CONFIG.SYS. With the /MAXCPU=1 switch the system won’t start any of the secondary CPUs. This will reduce the processor power requirements and will also allow the processor to run cooler. This can also reduce bus noise and load system-wide.