Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 62a07e6e authored by Jesper Juhl's avatar Jesper Juhl Committed by Linus Torvalds
Browse files

[PATCH] ksymoops related docs update 



Update ksymoops related documentation to reflect current 2.6 reality.

Signed-off-by: default avatarJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent 55032eac

Documentation/Changes

+8 −3
Original line number Diff line number Diff line
@@ -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

-----------------

Documentation/filesystems/devfs/README

+0 −5
Original line number Diff line number Diff line
@@ -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.

Documentation/networking/decnet.txt

+0 −2
Original line number Diff line number Diff line
@@ -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

Documentation/oops-tracing.txt

+1 −1
Original line number Diff line number Diff line 
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

Documentation/video4linux/bttv/README.freeze

+3 −3
Original line number Diff line number Diff line
@@ -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