ksymoops.8

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

unavailable.

Do you detect a slight note of inconsistency in the above?
.SH ADDRESS TO SYMBOL CONVERSION
.P
Addresses are converted to symbols based on the symbols in vmlinux,
/proc/ksyms, object files for modules and System.map, or as many of
those sources as ksymoops was told to read.  ksymoops uses as many
symbol sources as you can provide, does cross checks between the
various sources to identify any discrepancies and builds a merged map
containing all symbols, including loaded modules where possible.
.P
Symbols which end in _R_xxxxxxxx (8 hex digits) or _R_smp_xxxxxxxx are
symbol versioned, see genksyms(8).  ksymoops strips the _R_... when
building its internal system map.
.P
Module symbols do not appear in vmlinux nor System.map and only
exported symbols from modules appear in /proc/ksyms.  Therefore
ksymoops tries to read module symbols from the object files specified
by \fB-o\fR.  Without these module symbols, diagnosing a problem in a
module is almost impossible.
.P
There are many problems with module symbols, especially with versions
of insmod(8) up to and including 2.1.121.  Some modules do not export
\fIany\fR symbols, there is no sign of them in /proc/ksyms so they are
effectively invisible.  Even when a module exports symbols, it
typically only exports one or two, not the complete list that is really
needed for Oops diagnosis.  ksymoops can build a complete symbol table
from the object module but it has to
.HP 4m
(a)\ Know that the module is loaded.
.HP 4m
(b)\ Find the correct object file for that module.
.HP 4m
(c)\ Convert section and symbol data from the module into kernel
addresses.
.P
If a module exports no symbols then there is no way for ksymoops to
obtain any information about that module.  lsmod says it is loaded but
without symbols, ksymoops cannot find the corresponding object file nor
map offsets to addresses.  Sorry but that is the way it is, if you Oops
in a module that displays no symbols in ksyms, forget it\ :(.
.P
When a module exports symbols, the next step is to find the object file
for that module.  In most cases the loaded module and the object file
has the same basename but that is not guaranteed.  For example,
  insmod uart401 -o xyz
.br
will load uart401.o from your module directories but store it as xyz.
Both ksyms and lsmod say module name 'xyz' with no indication that the
original object file was uart401.  So ksymoops cannot just use the
module name from ksyms or lsmod, it has to do a lot more work to find
the correct object.  It does this by looking for a unique match between
exported symbols and symbols in the module objects.
.P
For every file obtained from the \fB-o\fR option(s), ksymoops extracts
all symbols (both static and external), using nm(1).  It then runs the
exported module symbols in ksyms and, for every exported module symbol,
it does a string compare of that symbol against every symbol in every
object.  When ksymoops finds a module symbol that is exported in ksyms
and appears exactly \fBonce\fR amongst all the \fB-o\fR objects then it
has to assume that the object is the one used to load the module.  If
ksymoops cannot find any match for any exported symbol in a module or
finds more than one match for every exported symbol in a module then it
cannot determine which object was actually loaded.
.P
After ksymoops has matched a loaded module against an object using a
unique symbol, it still has to calculate addresses for the symbols from
the object.  To do this, ksymoops first needs the start address of the
text, data and read only data sections in the loaded module.  Given the
start address of a section, ksymoops can calculate the kernel address
of every symbol in that section and add the symbols to the combined
system map, this includes symbols that are not exported.  Unfortunately
the start address of a section is only available if the module exports
at least one symbol from that section.  For example, if a module only
exports text symbols (the most common case) then ksymoops can only
calculate the start of the text section and has to discard symbols from
the data and read only data sections for that module, reducing the
information available for diagnosis.
.P
When multiple symbol sources are available and those symbol sources
contain a kernel version number, ksymoops compares all the version
numbers.  It flags a warning if there is any mismatch.  One of the more
common causes of problems is force loading a module from one kernel
into a different kernel.  Even if it was deliberate, it needs to be
highlighted for diagnosis.
.P
When both ksyms and lsmod are available, the list of modules extracted
from ksyms is compared against the list of modules from lsmod.  Any
difference is flagged as a warning, it typically indicates invisible
modules.  However it can also be caused by a mismatch between ksyms and
lsmod.
.P
When multiple symbol sources are available, ksymoops does cross checks
between them.  Each check is only performed if both symbol sources are
present and non-empty.  Every symbol in the first source should appear
in the second source and should have the same address.  Where there is
any discrepancy, one of the sources takes precedence, the precedence is
somewhat arbitrary.  Some discrepancies are silently ignored because
they are special cases but the vast majority of symbols are expected to
match.
.HP 2m
*\ Exported module symbols in ksyms are compared against the symbols
in the corresponding object file.  ksyms takes precedence.
.HP 2m
*\ The kernel (non module) symbols from ksyms are compared against
vmlinux.  vmlinux takes precedence.
.HP 2m
*\ The symbols from System.map are compared against vmlinux.  vmlinux
takes precedence.
.HP 2m
*\ The symbols from vmlinux are compared against System.map.  vmlinux
takes precedence.  These two sources are compared in both directions,
they should be identical.
.HP 2m
*\ The kernel (non module) symbols from ksyms are compared against
System.map.  System.map takes precedence.
.P
After reading and cross checking all the symbol sources, they are
merged into a single system map.  Duplicate symbols, registers (type a)
and static 'gcc2_compiled.' symbols are dropped from the merged map.
Any symbols with an address below 4096 are discarded, these are symbols
like Using_Versions which has an address of 0.
.P
Given all the above processing and deduction, it is obvious that the
merged system map cannot be 100% reliable, which means that conversion
of addresses to symbols cannot be reliable.  The addresses are valid
but the symbol conversion is only as good as the symbol sources you fed
into ksymoops.
.P
/proc/ksyms and /proc/lsmod are volatile so unless ksymoops gets the
current ksyms, you always have to question the validity of the module
information.  The only way I know to (almost) guarantee valid ksyms is
to use ksymoops in one shot mode (see option \fI-1\fR).  Then ksymoops
reads the log and decodes Oops in real time.
.SH KSYMOOPS SUPPORT IN MODUTILS
.P
Modutils 2.3.1 onwards has support to make oops debugging easier,
especially for modules.  See insmod(8) for details.  If you want
automatic snapshots of ksyms and lsmod data as modules are loaded and
unloaded, create /var/log/ksymoops, it should be owned by root with
mode 644 or 600.  If you do not want automatic snapshots, do not create
the directory.  A script (insmod_ksymoops_clean) is provided by
modutils to delete old versions, this should be run by cron once a day.
.SH OUTPUT
.P
ksymoops prints all lines that contain text which might indicate a
kernel problem.  Due the complete lack of standards in kernel error
messages, I cannot guarantee that all problem lines are printed.  If
you see a line in your logs which ksymoops should extract but does not,
contact the maintainer.
.P
When ksymoops sees EIP/PC/NIP/TPC lines, call trace lines or code
lines, it prints them and stores them for later processing.  When the
code line is detected, ksymoops converts the EIP/PC/NIP/TPC address and
the call trace addresses to symbols.  These lines have ';' after the
header instead of ':', just in case anybody wants to feed ksymoops
output back into ksymoops, these generated lines are ignored.
.P
Formatted data for the program counter, trace and code is only output
when the Code: line is seen.  If any data has been stored for later
formatting and more than 5 lines other than Oops text or end of file
are encountered then ksymoops assumes that the Code: line is missing or
garbled and dumps the formatted data anyway.  That should be fail safe
because the Code: line (or its equivalent) signals the end of the Oops
report.  Except for sparc64 on SMP which has a register dump
\fIafter\fR the code.  ksymoops tries to cater for this exception.
Sigh.
.P
Addresses are converted to symbols wherever possible.  For example

.nf
  >>EIP; c0113f8c <sys_init_module+49c/4d0>
  Trace; c011d3f5 <sys_mremap+295/370>
  Trace; c011af5f <do_generic_file_read+5bf/5f0>
  Trace; c011afe9 <file_read_actor+59/60>
  Trace; c011d2bc <sys_mremap+15c/370>
  Trace; c010e80f <do_sigaltstack+ff/1a0>
  Trace; c0107c39 <overflow+9/c>
  Trace; c0107b30 <tracesys+1c/23>
  Trace; 00001000 Before first symbol
.fi
.P
Each converted address is followed by the nearest symbol below that
address.  That symbol is followed by the offset of the address from the
symbol.  The value after '/' is the "size" of the symbol, the
difference between the symbol and the next known symbol.  So
  >>EIP; c0113f8c <sys_init_module+49c/4d0>
means that the program counter was c0113f8c.  The previous symbol is
sys_init_module, the address is 0x49c bytes from the start of the
symbol, sys_init_module is 0x4d0 bytes long.  If you prefer decimal
offsets and lengths see option \fB-x\fR.  If the symbol comes from a
module, it is prefixed by '[\fImodule_name\fR]', several modules have
the same procedure names.
.P
The use of 'EIP' for program counter above is for ix86.  ksymoops tries
to use the correct acronym for the program counter (PC, NIP, TPC etc.)
but if it does not recognize the target hardware, it defaults to EIP.
.P
When a Code: line is read, ksymoops extracts the code bytes.  It uses
the program counter line together with the code bytes to generate a
small object file in the target architecture.  ksymoops then invokes
objdump(1) to disassemble this object file.  The human readable
instructions are extracted from the objdump output and printed with
address to symbol conversion.  If the disassembled code does not look
sensible, see the \fI-e\fR, \fI-a\fR and \fI-t\fR options.
.P
\fBTAKE ALL SYMBOLS, OFFSETS AND LENGTHS WITH A PINCH OF SALT!\fR
The addresses are valid but the symbol conversion is only as good as
the input you gave ksymoops.  See all the problems in "ADDRESS TO SYMBOL
CONVERSION" above.  Also the stack trace is potentially ambiguous.  The
kernel prints any addresses on the stack that \fBmight\fR be valid
addresses.  The kernel has no way of telling which (if any) of these
addresses are real and which are just lying on the stack from previous
procedures.  ksymoops just decodes what the kernel prints.
.SH ENVIRONMENT VARIABLES
.TP
KSYMOOPS_NM
Path for nm, defaults to ${INSTALL_PREFIX}/bin/${CROSS}nm.
.TP
KSYMOOPS_FIND
Path for find, defaults to /usr/bin/find.
.TP
KSYMOOPS_OBJDUMP
Path for objdump, defaults to ${INSTALL_PREFIX}/bin/${CROSS}objdump.
.SH CROSS SYSTEM OOPS DIAGNOSIS
.P
To process an Oops from one system on another, you need access to all
the symbol sources, including modules, System.map, ksyms etc.  If the
two systems are different hardware, you also need versions of the nm
and objdump commands that run on your system but handle the target
system.  You also need versions of libbfd, libopcodes, and libiberty
that handle the target system.  Consult the binutils documentation
for instructions on how to build cross system versions of these
utilities.
.P
To override the default versions of nm and find, use the environment
variables above.  To use different versions of libbfd and libiberty,
use the --rpath option when linking ksymoops or the LD_LIBRARY_PATH
environment variable when running ksymoops.  See the info pages for ld
and /usr/doc/glibc*/FAQ.
You can also build a version of ksymoops that is dedicated to the cross
compile environment by using the BFD_PREFIX, DEF_TARGET, DEF_ARCH and
CROSS options at build time.
See INSTALL in the ksymoops source package for more details.
.SH DIAGNOSTICS
.HP 4m
0\ -\ normal.
.HP 4m
1\ -\ error(s) or warning(s) issued, results may not be reliable.
.HP 4m
2\ -\ fatal error, no useful results.
.HP 4m
3\ -\ One shot mode, end of input was reached without seeing an Oops.
.SH BUGS
Because of the plethora of possible kernel error and information
strings, ksymoops's pattern matching sometimes prints lines that are
not errors at all.  For example, a line starting with 3c589 matches the
pattern for a call trace line, both start with at least 4 hex digits.
Humans are smarter than programs, ignore spurious lines.
.SH AUTHORS
Keith Owens <[e-mail]> - maintainer.

Patches from Jakub Jelinek <[e-mail]>, Richard Henderson
<[e-mail]>.
.SH HISTORY
The original ksymoops.cc was written by Greg McGary
<[e-mail]> and updated by Andreas Schwab
<[e-mail]>.  That version required C++
and supported only ix86 and m68k.
.P
To get the equivalent of the old ksymoops.cc (no vmlinux, no modules,
no ksyms, no System.map) use ksymoops\ -VKLOM.  Or to just read
System.map, ksymoops\ -VKLO\ -m\ mapfile.
.SH SEE ALSO
.P
find(1),  insmod(8), nm(1), objdump(1), rmmod(8), dmesg(8),
genksyms(8), syslogd(8).  bfd info files.