[PATCH] ksymoops related docs update

From: Jesper Juhl
Date: Sat Oct 15 2005 - 13:39:20 EST

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

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

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

--- 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/