[PATCH] ksymoops related docs update

[Jesper Juhl <jesper.juhl@gmail.com>]

After getting some feedback on the initial version of this patch
I decided to rework it a bit and also update *all* references to
ksymoops in Documentation/ instead of only the Changes file.

Please consider merging.


Update ksymoops related documentation to reflect current 2.6 reality.

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---

 Documentation/Changes                        |   11 ++++++++---
 Documentation/filesystems/devfs/README       |    5 -----
 Documentation/networking/decnet.txt          |    2 --
 Documentation/oops-tracing.txt               |    2 +-
 Documentation/video4linux/bttv/README.freeze |    6 +++---
 5 files changed, 12 insertions(+), 14 deletions(-)

--- linux-2.6.14-rc4-git4-orig/Documentation/Changes	2005-10-11 22:40:49.000000000 +0200
+++ linux-2.6.14-rc4-git4/Documentation/Changes	2005-10-15 20:28:26.000000000 +0200
@@ -139,9 +139,14 @@
 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
 -----------------
--- linux-2.6.14-rc4-git4-orig/Documentation/filesystems/devfs/README	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.14-rc4-git4/Documentation/filesystems/devfs/README	2005-10-15 20:28:51.000000000 +0200
@@ -1812,11 +1812,6 @@
 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.
--- linux-2.6.14-rc4-git4-orig/Documentation/networking/decnet.txt	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.14-rc4-git4/Documentation/networking/decnet.txt	2005-10-15 20:29:04.000000000 +0200
@@ -176,8 +176,6 @@
  - 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
--- linux-2.6.14-rc4-git4-orig/Documentation/oops-tracing.txt	2005-10-11 22:40:49.000000000 +0200
+++ linux-2.6.14-rc4-git4/Documentation/oops-tracing.txt	2005-10-15 20:29:44.000000000 +0200
@@ -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
--- linux-2.6.14-rc4-git4-orig/Documentation/video4linux/bttv/README.freeze	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.14-rc4-git4/Documentation/video4linux/bttv/README.freeze	2005-10-15 20:30:17.000000000 +0200
@@ -27,9 +27,9 @@
 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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/