Determining the kernel component that failed
The information given by the
panic and trap commands of the
command tells you which routines were executing
just before the panic.
Because the entire kernel
(all kernel operating system code
plus all driver code)
is linked together into one executable file,
this does not tell you which component caused the problem.
Knowing which component contains the problematic function
can sometimes tell you if the problematic function
is part of the operating system,
or if it is part of a driver supplied by another vendor.
This information can be extracted using the
command or, for systems where the SCO OpenServer Development System is
Both methods are detailed below.
The following hints are provided
for users who are not familiar with device driver conventions:
If a routine is mentioned in a file named Driver.o,
it is usually part of a device driver,
and the driver prefix is the name of the directory
in which the Driver.o file is located.
If a function name ends in
``read'', ``write'', or ``ioctl'',
it is part of a character device driver.
If a function name ends in ``strategy'',
it is part of a block device driver.
Functions that end in ``open'' or ``close''
can be part of either a character or block device driver.
Kernel utility functions are used in drivers
much as system calls and library routines
are used in user-level code.
Manual pages for SCO OpenServer kernel functions
are included in the Consolidated HDK,
available on media or at
These manual pages can also be viewed at
Some of the most frequently used functions are:
all drivers (Section D3oddi)
block drivers (Section D3oddi)
STREAMS drivers (Section D3str)
Using strings(C) to find kernel component
Examining a kernel stack trace
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003