STREAMS/UX for the HP 9000 Reference Manual

192
Debugging STREAMS/UX Modules and Drivers
Using adb
Obtaining Values from the Process Table Entry and User Area
It is possible to use adb to print out fields of interest from the process table
entry and user area of the process that was running when the system crashed.
The following subsection describes how to print certain important fields and
gives a very brief description of each field. For more information on the
meaning of these fields, see The Design of the UNIX Operating System by
Maurice Bach, pub. Prentice-Hall, or The Design and Implementation of the
4.3 BSD UNIX Operating System by Leffler, McKusick, Karels and
Quarterman, pub. Addison-Wesley.
adb, when called with the -k option, should print out the address of the user
area and process table entry of the process that was running when the system
crashed. adb will print this out when it is first entered, so the first output you
should see from adb is:
u 7FFE6000 u.u_procp 4D2F20
u is the location of the user area, and should always be at virtual address
7FFE6000. When the kernel switches to a new process, it always maps the
physical address of the process' user area to virtual address 7FFE6000.
u.u_procp is the location of this process' process table entry. This address
will vary from process to process. If adb does not print the u and u.u_procp
values on entry, it was unable to determine the currently running process at
crash time. adb was unable to print these values probably because your core
dump was the result of a Transfer of Control (TOC).
If the process that caused the panic was running on the Interrupt Control
Stack (ICS), the u and u.u_procp pointers will not contain valid information
for the process. When an interrupt occurs the kernel executes the appropriate
kernel code to process the interrupt without switching to a new user context.
The u and u_procp address which adb will print will be the process that was
running when the interrupt occurred. The interrupt interrupted the running
of that process in order to process the interrupt. Look at the panic message
in msgbuf to tell if the panic occurred while on the ICS. If you see a
message like the following after the hex stack trace, the process was on the
ICS.
NOT sync'ing disks (on the ICS) (0 buffers to flush):