Debugging the Uniaud drivers
If you open a ticket, additional information will almost always be necessary. You can save a lot of time by always attaching the log file created by the testlog.cmd program to your ticket when you open it, rather than waiting for the developer to ask for it.
Known Problems and Limitations
If you are using ACPI.PSD, you must have version 3.20.01 or later. Uniaud32 will not work with ACPI.PSD versions older than 3.20.01.
Capturing a testlog log file
If you don't already have the current version of testlog.cmd, you can download it here: Get testlog.cmd
Open a command window and execute the testlog command:
Attach the created log file to your ticket. Do not ZIP the log file.
Real Time Logs
You can see the log output in real time by connecting a terminal or second system to the serial port.
Enable the serial output by adding the "/P:1" or the "/P:2" switch to Uniaud32.sys in your config.sys. /P:1 specifies to use serial port 1, and /P:2 specifies to use serial port 2.
Set the serial port baud rate to 115200, 8 bits, no parity.
If you are getting kernel or driver exceptions, a trap dump volume can often get you the data to figure out where and why this is happening. See http://home.earthlink.net/~steve53/os2diags/TrapDumpRef.txt for a setup guide.
The Kernel Debugger
There are times when you just has to watch the code execute to understand the issue. The kernel debugger can help here. You need a second system and either a serial port to or a supported NIC to use the debugger. You can not use a NIC for debugging driver initialization and such. Not enough of the OS is loaded. However, NIC debugging can make working other areas of driver operation go faster.
The kernel debugger comes in two flavors. There's the traditional command line debugger and there's the ICAT source level GUI debugger. Which is best depends on which part of the driver code you are working on. The source level debugging is handy, but it can be slow over a serial port.
More to come...