Watchdog analysis

Since you may not get a good core file, the PROM commands will be necessary to give you the current state of the system at the point of failure. You may be able to look at other things in a core image, such as the other processes and their stacks, but much of the data about the currently running process or thread will be unavailable. The PROM commands may allow you to find the routines, at least, that were in use at the time the reset occurred.

Since watchdog resets only occur when the system is processing traps, the actual PC value will not be of much use: You can guarantee that it's going to be in the kernel trap-handling code. The trace information is the most important and useful output.

Note that when you are using the PROM, the kernel is not running and the symbol table is not available to the PROM code. This means your output from the PROM commands will be entirely in hexadecimal. All you can get is raw numeric addresses. Once the system is rebooted, you can try to associate these with the functions in the kernel by running adb on the live system, using the command address/i to display the instruction and location of each address taken from the stack trace.

This is one instance where it may actually be better to run the debugger on /kernel/unix , for Solaris 2, rather than on the standard /dev/ksyms . You cannot be sure that the modules loaded on a rebooted system will be the same, or in the same order, as they were loaded on the original crashed system. The only locations where you can guarantee that the names are correct will be those in the static, booted kernel. The SunOS 4.x kernel is already static, so the addresses can be applied to the newly booted system without any fear that things will have moved around.