Drivers and crashes

In general, although debugging drivers is supposedly the responsibility of the driver writer, bugs can sneak past even the most dedicated tester. Unless you wrote the code yourself or have access to the author, most of your debugging will be limited to trying to verify that the driver is causing the problem. There are some basic steps you can perform that will help.

• Monitor the use of the device, if possible, and see if crashes can be associated with initial access or heavy use of the driver.

• Look for console messages that may identify hardware problems. Many drivers will log error conditions.

• See if the driver has options you can set, either via the /etc/system file or by using adb to modify the data in the running kernel, that will print debugging information.

• In Solaris 2, try using the /etc/system file to set the high-order bit in the variable moddebug . Setting the bit will instruct the system to print a message on the console every time a kernel module is loaded or unloaded.

• Examine all the processes on the system to see if any of them are using the suspect device. The stack tracebacks for each process on SunOS 4.x (with the traceall macro) or thread on Solaris 2 (with the threadlist macro) might allow you to identify the fact that a device is actively in use, even though the driver functions do not actually appear in the stack trace for the process that caused the panic.

Especially when working with new drivers, getting several core dumps may be a necessity. Having more than one crash to look at will help to identify common features or characteristics. And last but not least, since drivers deal so closely with hardware, what appears to be a driver problem may just be an indication that the device itself is having trouble. Cabling, line termination, and even power supply problems can have drastic and very misleading effects.