luck/tmp_suning_uos_patched
1
0
Fork 1
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[PATCH] ksymoops related docs update

Browse Source 
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 2005-11-07 01:01:03 -08:00 committed by Linus Torvalds
parent 55032eacdb
commit 62a07e6e9e
5 changed files with 12 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/Changes
View File

@ -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
-----------------

5
Documentation/filesystems/devfs/README
View File

@ -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.

2
Documentation/networking/decnet.txt
View File

@ -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

2
Documentation/oops-tracing.txt
View File

@ -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

6
Documentation/video4linux/bttv/README.freeze
View File

@ -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