[PATCH] ksymoops related docs update
Update ksymoops related documentation to reflect current 2.6 reality. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This commit is contained in:
Jesper Juhl
Linus Torvalds
parent
55032eacdb
commit
62a07e6e9e
|
|
@ -139,9 +139,14 @@ You'll probably want to upgrade.
|
|||
Ksymoops
|
||||
--------
|
||||
|
||||
If the unthinkable happens and your kernel oopses, you'll need a 2.4
|
||||
version of ksymoops to decode the report; see REPORTING-BUGS in the
|
||||
root of the Linux source for more information.
|
||||
If the unthinkable happens and your kernel oopses, you may need the
|
||||
ksymoops tool to decode it, but in most cases you don't.
|
||||
In the 2.6 kernel it is generally preferred to build the kernel with
|
||||
CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is
|
||||
(this also produces better output than ksymoops).
|
||||
If for some reason your kernel is not build with CONFIG_KALLSYMS and
|
||||
you have no way to rebuild and reproduce the Oops with that option, then
|
||||
you can still decode that Oops with ksymoops.
|
||||
|
||||
Module-Init-Tools
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -1812,11 +1812,6 @@ it may overflow the messages buffer, but try to get as much of it as
|
|||
you can
|
||||
|
||||
|
||||
if you get an Oops, run ksymoops to decode it so that the
|
||||
names of the offending functions are provided. A non-decoded Oops is
|
||||
pretty useless
|
||||
|
||||
|
||||
send a copy of your devfsd configuration file(s)
|
||||
|
||||
send the bug report to me first.
|
||||
|
|
|
|||
|
|
@ -176,8 +176,6 @@ information (_most_ of which _is_ _essential_) includes:
|
|||
- Which client caused the problem ?
|
||||
- How much data was being transferred ?
|
||||
- Was the network congested ?
|
||||
- If there was a kernel panic, please run the output through ksymoops
|
||||
before sending it to me, otherwise its _useless_.
|
||||
- How can the problem be reproduced ?
|
||||
- Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of
|
||||
tcpdump don't understand how to dump DECnet properly, so including
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format
|
||||
(from dmesg, etc). Ignore any references in this or other docs to "decoding
|
||||
the Oops" or "running it through ksymoops". If you post an Oops fron 2.6 that
|
||||
the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that
|
||||
has been run through ksymoops, people will just tell you to repost it.
|
||||
|
||||
Quick Summary
|
||||
|
|
|
|||
|
|
@ -27,9 +27,9 @@ information out of a register+stack dump printed by the kernel on
|
|||
protection faults (so-called "kernel oops").
|
||||
|
||||
If you run into some kind of deadlock, you can try to dump a call trace
|
||||
for each process using sysrq-t (see Documentation/sysrq.txt). ksymoops
|
||||
will translate these dumps into kernel symbols too. This way it is
|
||||
possible to figure where *exactly* some process in "D" state is stuck.
|
||||
for each process using sysrq-t (see Documentation/sysrq.txt).
|
||||
This way it is possible to figure where *exactly* some process in "D"
|
||||
state is stuck.
|
||||
|
||||
I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
|
||||
for some people. Thus probably a small buglet left somewhere in bttv
|
||||
|
|
|
|||
Reference in New Issue