Testing Guidelines

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

You should be able to install the retail build initially. The PSD= line in your config.sys should not have any switches. This is the normal configuraton and should work for every system:

PSD=ACPI.PSD

This default, normal configuration attempts to start the system in Symmetric Mode, or APIC mode 2, or just Mode 2. You can always tell what mode the system is running in by using the AcpiStat utility included in the distribution package. In fact, the AcpiStat utility is the only way to determine what mode the system is running in. If this normal configuration doesn't work properly additional steps can be taken to restrict the PSD operation.

If you suspect IO interrupt configuration issues, you can try using the /VW switch. The /VW switch is also required if you have older device drivers that do not handle interrupt numbers higher than 15. When the /VW switch is used, the PSD does not alter the IO interrupt configuration from the way the BIOS has set it up. The APICs are enabled and multiple CPUs are enabled. ACPI and OEMHELP services are also available. This is known as Virtual Wire mode or APIC mode 1, or just Mode 1.

If you suspect multiple CPU issues such as reentrancy problems you can prevent the kernel from initializing CPUs by using the /MAXCPU=1 switch. Inter-cpu IPIs are also not used when only one cpu is initialized. This switch can be used with or without other switches.

You can disable almost all of the configuration that the PSD does by using the /PIC switch. When the /PIC switch is used, the PSD doesn't touch any of the interrupt configuration, and it doesn't touch any of the APICs. As a result, only 1 CPU will be initialized. This system configuration remains in the state that BIOS has setup except that the PSD may have enabled some PCI devices that were disabled by the BIOS. The only reason you would want to run a system with the /PIC switch is for testing purposes. ACPI and OEMHELP services are still available in this mode. This is know as PIC mode, or Mode 0.

Your testing order should be:

1. PSD=ACPI.PSD
   If the system boots ok -> done.
   If the system won't boot, how far does it get?

a) If it stops when the desktop starts (Snap logo or blue screen), your problem is probably not with the PSD. Make sure you have the updated keyboard driver (10.163 or later), doscall1.dll (10-Nov-2011 or later), etc. If you have a multi-core system you can also try the /MAXCPU=1 switch.

b) If it stops after the chkdsks run but before the desktop starts, probably one of the drivers is having trouble initializing. Use ALT-F4 to load the drivers one at a time and see which one is failing.

c) Otherwise, go to step 2

2. PSD=ACPI.PSD /VW
   If the system boots ok -> Check to make sure all of your drivers support interrupts greater than 15. If any of them do not, then this is how you need to run your system. Otherwise, collect a testlog log and a serial port log as described below.

If the system won't boot, how far does it get?

a) If it stops when the desktop starts (Snap logo or blue screen), your problem is probably not with the PSD. Make sure you have the updated keyboard driver (10.163 or later), doscall1.dll (10-Nov-2011 or later), etc. If you have a multi-core system you can also try the /MAXCPU=1 switch.

b) If it stops after the chkdsks run but before the desktop starts, probably one of the drivers is having trouble initializing. Use ALT-F4 to load the drivers one at a time and see which one is failing.

c) Otherwise, go to step 3

3. rem PSD=ACPI.PSD
   if the system boots ok -> goto step 4
   if the system won't boot -> fix your system first before testing the PSD

4. PSD=ACPI.PSD /PIC
   if the system boots ok -> Collect a testlog log and collect a serial port log as described below.
   if the system won't boot -> collect a serial port log as described below.

Collecting Logs, Reporting Problems, and Submitting Tickets

Collecting a testlog log

1. Install the debug package from the Warpin package and copy the debug version of ACPI.PSD to \OS2\BOOT on your boot disk.
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. 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.
5. Attach the ZIP file to your ticket.

Collecting a serial port log

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. 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.
2. Another computer that will capture the serial data.
3. 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. Comment out (using REM) the APM.ADD driver and the AcpiDaemon RUN statement.
5. 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.