ksymoops.8

kdb-v4.3-2.4.20-common-1.bz2 键盘的驱动啊 克里斯蒂警方可死了地方军

Normally, ksymoops reads its entire input file and extracts all Oops
reports.  If the -1 toggle is set, it will run in one shot mode and
exit after the first Oops.  This is useful for automatically mailing
reports as they happen, like this\ :-

.nf
    #!/bin/sh
    # ksymoops1
    while (true)
    do
	ksymoops -1 > $HOME/oops1
	if [ $? -eq 3 ]
	then
	   exit 0  # end of input, no Oops found
	fi
	mail -s Oops admin < $HOME/oops1
    done

    tail -f /var/log/messages | ksymoops1
.fi

Restarting the tail command after log rotation is left as an exercise
for the reader.

In one shot mode, reading of the various symbol sources is delayed
until ksymoops sees the first program counter, call trace or code line.
This ensures that the current module information is used.  The downside
is that any parameter errors are not detected until an Oops actually
occurs.
.P
The default is to read everything from the Oops.file, extracting and
processing every Oops it finds.  Note that the default method reads the
symbol sources once and assumes that the environment does not change
from one Oops to the next, not necessarily valid when you are using
modules.
.TP
\fB-i\fR\ \fB--ignore-insmod-path\fR
When you are using an initial ramdisk for modules, the path name to the
modules is typically just /lib.  That pathname is recorded in the
__insmod..._O symbol in ksyms but ksymoops cannot find the files in the
real /lib, so it issues warning messages.  If you specify -i then
ksymoops ignores the path name in __insmod...O symbols, instead it
searchs the -o paths (if any) looking for the object with the correct
basename and timestamp.  -i is recommended when loading modules from a
ramdisk.  This assumes that the -o paths contain the modules used to
build the ramdisk, with the same timestamp.
.P
Default is to use the path from __insmod...O symbols.
.TP
\fB-I\fR\ \fB--ignore-insmod-all\fR
Use this toggle if you want to completely ignore all insmod(8) assistance
information (symbols starting with __insmod in ksyms).  This includes
module paths, timestamps, section start and length etc.  Then ksymoops
will fall back on the old method of matching symbols to module objects,
using the -o paths (if any).  It is hard to think of a legitimate
reason to use -I, -i is better if your only problem is a path name
mismatch.
.P
Default is to use the path from __insmod...O symbols and section
information from __insmod...S symbols.
.TP
\fB-T\ \fItruncate\fR\ \fB--truncate=\fItruncate\fR
If your binutils are configured for multiple targets, they tend to
print addresses using the address size of the largest target.  If the
other inputs to ksymoops have shorter symbol sizes, the different
representations cause symbols which should have the same address to
appear at different addresses.  This is a particular problem when
building for mixed 32 and 64 bit targets.  To remove the ambiguity,
use \fB--truncate=\fItruncate\fR.  A value of 0 means no truncation, a
value greater than 8*sizeof(unsigned long) is silently converted to 0.
.P
Default is \fB--truncate=\fI0\fR, no truncation.
.TP
\fB-d\fR\ \fB--debug\fR
Each occurrence of \fB-d\fR increases the debugging level of ksymoops
by one.
.IP Level\ 1
Regular expression compile summaries.
Before and after text for *[mns] expansion.
Option processing, but only for options appearing after \fB-d\fR.
Entry to the main processing routines.
KSYMOOPS_ environment variables.
Object files extracted directly from ksyms.
Information on matches between loaded modules and module objects.
Filename of the Oops report.
Version number for the oops.
Saving merged system map.
.IP Level\ 2
Summary information on symbol table sizes.
Every version number found in the oops.
Comparing symbol maps.
Appending symbol maps.
Full pathname of a program.
External commands issued.
Progress reports for \fB-o\ \fIobject\fR.
The names of '*.o' files found in a \fB-o\fR directory.
Offset adjustments for module sections.
Every line output from running objdump on the code bytes.
.IP Level\ 3
Every input line from Oops.file.
Non-duplicate and low address symbols dropped from the merged system map.
Mapping of addresses to symbols.
.IP Level\ 4
Every input line from all sources, this prints duplicate lines.
The return code from every regexec call.
Ambiguous matches that are ignored.
Every symbol added to every table.
Copying symbol tables.
Increases in symbol table sizes.
Entry to some lower level routines.
Every symbol dropped.
.IP Level\ 5
For matching regexecs, details on every substring.
.P
Default is no debugging.
.TP
\fB-h\fR\ \fB--help\fR
Prints the help text and the current defaults.
.TP
\fB-t\ \fItarget\fR\ \fB--target=\fItarget\fR
Normally you do Oops diagnosis using the same hardware as the Oops
itself.  But sometimes you need to do cross system Oops diagnosis,
taking an Oops from one type of hardware and processing it on an
another.  For example, when you are porting to a new system or you are
building an embedded kernel.  To do cross system Oops processing, you
must tell ksymoops what the target hardware is, using
\fB-t\ \fItarget\fR, where \fItarget\fR is a bfd target name.  You can
find out which targets your machine supports by

  ksymoops -t '?'
.P
Default is the same target as ksymoops itself, with one exception.  On
sparc64, the kernel uses elf64-sparc but user programs are elf32-sparc.
If \fB-t\ \fItarget\fR was not specified and ksymoops was compiled for
elf32-sparc and the Oops contains a TPC line then ksymoops
automatically switches to -t\ elf64-sparc.
.TP
\fB-a\ \fIarchitecture\fR\ \fB--architecture=\fIarchitecture\fR
To do cross system Oops processing, you must tell ksymoops what the
target architecture is, using \fB-a\ \fIarchitecture\fR, where
\fIarchitecture\fR is a bfd architecture name.  You can find out which
architectures your machine supports by

  ksymoops -a '?'
.P
Default is the same architecture as ksymoops itself, with one
exception.  On sparc64, the kernel uses sparc:v9a but user programs are
sparc.  If \fB-a\ \fIarchitecture\fR was not specified and ksymoops was
compiled for sparc and the Oops contains a TPC line then ksymoops
automatically switches to -a\ sparcv:9a.
.TP
\fB-A\ \fI"address list"\fR\ \fB--addresses=\fI"address list"\fR If you
have a few adhoc addresses to convert to symbols, you can specify them
explicitly using \fB-A\ \fI"address list"\fR.  Any words in the list
that appear to be addresses are converted to symbols.  Punctuation
characters and non-address words are silently ignored, leading 0x on
addresses is also ignored, so you can paste text including words and
only the addresses will be processed.
.TP
\fBOops.file\ ...\fR
ksymoops accepts zero or more input files and reads them all.  If no
files are specified on the command line and no addresses are supplied
via \fB-A\fR then ksymoops reads from standard input.  You can even
type the Oops text directly at the terminal, although that is not
recommended.
.SH INPUT
.P
ksymoops reads the input file(s), using regular expressions to select
lines that are to be printed and further analyzed.  You do not need to
extract the Oops report by hand.
.P
All tabs are converted to spaces, assuming tabstop=8.  Where the text
below says "at least one space", tabs work just as well but are
converted to spaces before printing.  All nulls and carriage returns
are silently removed from input lines, both cause problems for string
handling and printing.
.P
An input line can have a prefix which ksymoops will print as part of
the line but ignore during analysis.  A prefix can be from syslogd(8)
(consisting of date, time, hostname, 'kernel:'), from syslog-ng
(numbers and three other strings separated by '|'), it can be
'<\fIn\fR>' from /proc/kmsg or the prefix can just be leading spaces.
"start of line" means the first character after skipping all prefixes,
including all leading space.
.P
Every kernel architecture team uses different messages for kernel
problems, see Oops_read in oops.c for the full, gory list.  If you are
entering an Oops by hand, you need to follow the kernel format as much
as possible, otherwise ksymoops may not recognize your input.  Input is
not case sensitive.

.ne 3
A bracketed address is optional '[', required '<', at least 4 hex
digits, required '>', optional ']', optional spaces.  For example
[<01234567>] or <beaf>.

An unbracketed address is at least 4 hex digits, followed by optional
spaces.  For example 01234567 or abCDeF.

The sparc PC line is 'PSR:' at start of line, space, hex digits, space,
\'PC:', space, unbracketed address.

The sparc64 TPC line is 'TSTATE:' at start of line, space, 16 hex
digits, space 'TPC:', space, unbracketed address.

The ppc NIP line has several formats.  'kernel\ pc' 'trap\ at\ PC:'
\'bad\ area\ pc' or 'NIP:'.  Any of those strings followed by a single
space and an unbracketed address is the NIP value.

The mips PC line is 'epc' at start of line, optional space, one or more
\':', optional space, unbracketed address.

The ix86 EIP line is 'EIP:' at start of line, at least one space, any
text, bracketed address.

The x86_64 EIP line is 'RIP:' at start of line, at least one space, any
text, bracketed address.

The m68k PC line is 'PC' at start of line, optional spaces, '=',
optional spaces, bracketed address.

The arm PC line is 'pc' at start of line, optional spaces, ':',
optional spaces, bracketed address.

The IA64 IP line is ' ip', optional space, ':', optional space,
bracketed address.

A mips ra line is 'ra', optional spaces, one or more '=', optional
spaces, unbracketed address.

A sparc register dump line is ('i', '0' or '4', ':', space) or
('Instruction DUMP:', space) or ('Caller[').

The IA64 b0 line is 'b0', optional space, ':', optional space,
unbracketed address.  This can be repeated for other b registers, e.g.
b6, b7.

Register dumps have a plethora of formats.  Most are of the form \'name:
value' repeated across a line, some architectures use \'=' instead of
\':'.  See Oops_regs for the current list of recognised register names.
Besides the Oops_regs list, i370, mips, ppc and s390 have special
register dump formats, typically one register name is printed followed
by multiple values.  ksymoops extracts all register contents, but it only
decodes and prints register values that can be resolved to a kernel symbol.

A set of call trace lines starts with 'Trace:' or 'Call\ Trace:' or
\'Call\ Backtrace:' (ppc only) or 'Function\ entered\ at' (arm only) or
\'Caller[' (sparc64 only) followed by at least one space.

For 'Trace:' and 'Call\ Trace:', the rest of the line is bracketed
addresses, they can be continued onto extra lines.  Addresses can not
be split across lines.

For 'Call\ Backtrace:' (ppc only), the rest of the line is unbracketed
addresses, they can be continued onto extra lines.  Addresses can not
be split across lines.

For 'Function\ entered\ at' (arm only), the line contains exactly two
bracketed addresses and is not continued.

For 'Caller[' (sparc64 only), the line contains exactly one unbracketed
address and is not continued.

Spin loop information is indicated by a line starting with 'bh:\ ',
followed by lines containing reverse bracketed trace back addresses.
For some reason, these addresses are different from every other address
and look like this '<[hex]>\ <[hex]>' instead of the normal
\'[<hex>]\ [<hex>]'.

The Code line is identified by 'Instruction DUMP' or ('Code' followed
by optional spaces), ':', one or more spaces, followed by at least one
hex value.  The line can contain multiple hex values, each separated by
at least one space.  Each hex value must be 2 to 8 digits and must be a
multiple of 2 digits.

Any of the code values can be enclosed in <..> or (..), the last such
value is assumed to be the failing instruction.  If no value has <..>
or (..) then the first byte is assumed to be the failing instruction.

Special cases where Code: can be followed by text.  'Code: general
protection' or 'Code: <n>'.  Dump the data anyway, the code was