= 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 [[BR]] If the system boots ok -> done.[[BR]] 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[[BR]] 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 in the Collecting Logs section 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[[BR]] if the system boots ok -> goto step 4[[BR]] if the system won't boot -> fix your system first before testing the PSD 4. PSD=ACPI.PSD /PIC[[BR]] if the system boots ok -> Collect a testlog log and collect a serial port log as described in the Collecting Logs section below.[[BR]] if the system won't boot -> collect a serial port log as described in the Collecting Logs section below. = 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. Make a note of where you selected to install the debug files. Copy the following files from where ever the debug files were installed to \OS2\BOOT on your boot disk. * ACPI.PSD * APM.ADD (if used) == Collecting a Testlog Log == 1. If you did not install from the ACPI Warpin package, download "testlog" from http://www.88watts.net/software.html 2. Add the /DBGLVL=3 switch to the PSD= line in your CONFIG.SYS: 3. Reboot your system to start using the debug version of the software. 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 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. 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. 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. Edit the config.sys on the system under test and change the PSD line to: PSD=ACPI.PSD /DBGLVL=3 /OV 2. Comment out (using REM) the APM.ADD driver and the !AcpiDaemon RUN statement. 3. 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. 4. Boot the system under test. When it stops take a picture of the screen and attach the picture to your ticket. = Internal Processing Errors (IPE) = 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 cause by bad hardware. - An unsupported kernel is detected, or if any of the patches to the kernel fail, - An interrupt number specified by ACPI is higher than the maximum supported number.