wiki:DebuggingAndSuch

Version 3 (modified by stevenhl, 17 years ago) (diff)

--

Debugging the Uniaud drivers

Logging

The 32-bit drivers do some interal logging. To extract this data

copy alsa32$ alsa32.log
copy alsahlp$ alsahlp.log

It appears that the logs are cleared by the copy.

Trap Dumps

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