aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJesper Juhl <jesper.juhl@gmail.com>2005-11-07 04:01:03 -0500
committerLinus Torvalds <torvalds@g5.osdl.org>2005-11-07 10:53:54 -0500
commit62a07e6e9e93eda88a6eeb5009fc46d44ca60281 (patch)
tree6e5a0891a46b1d9864d5591a5961c63e1b818bea
parent55032eacdb3acf54f5ba2e4dd9205db2c5c0bce2 (diff)
[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>
-rw-r--r--Documentation/Changes11
-rw-r--r--Documentation/filesystems/devfs/README5
-rw-r--r--Documentation/networking/decnet.txt2
-rw-r--r--Documentation/oops-tracing.txt2
-rw-r--r--Documentation/video4linux/bttv/README.freeze6
5 files changed, 12 insertions, 14 deletions
diff --git a/Documentation/Changes b/Documentation/Changes
index 783ddc3ce4e8..86b86399d61d 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -139,9 +139,14 @@ You'll probably want to upgrade.
139Ksymoops 139Ksymoops
140-------- 140--------
141 141
142If the unthinkable happens and your kernel oopses, you'll need a 2.4 142If the unthinkable happens and your kernel oopses, you may need the
143version of ksymoops to decode the report; see REPORTING-BUGS in the 143ksymoops tool to decode it, but in most cases you don't.
144root of the Linux source for more information. 144In the 2.6 kernel it is generally preferred to build the kernel with
145CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is
146(this also produces better output than ksymoops).
147If for some reason your kernel is not build with CONFIG_KALLSYMS and
148you have no way to rebuild and reproduce the Oops with that option, then
149you can still decode that Oops with ksymoops.
145 150
146Module-Init-Tools 151Module-Init-Tools
147----------------- 152-----------------
diff --git a/Documentation/filesystems/devfs/README b/Documentation/filesystems/devfs/README
index 54366ecc241f..aabfba24bc2e 100644
--- a/Documentation/filesystems/devfs/README
+++ b/Documentation/filesystems/devfs/README
@@ -1812,11 +1812,6 @@ it may overflow the messages buffer, but try to get as much of it as
1812you can 1812you can
1813 1813
1814 1814
1815if you get an Oops, run ksymoops to decode it so that the
1816names of the offending functions are provided. A non-decoded Oops is
1817pretty useless
1818
1819
1820send a copy of your devfsd configuration file(s) 1815send a copy of your devfsd configuration file(s)
1821 1816
1822send the bug report to me first. 1817send the bug report to me first.
diff --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt
index c6bd25f5d61d..e6c39c5831f5 100644
--- a/Documentation/networking/decnet.txt
+++ b/Documentation/networking/decnet.txt
@@ -176,8 +176,6 @@ information (_most_ of which _is_ _essential_) includes:
176 - Which client caused the problem ? 176 - Which client caused the problem ?
177 - How much data was being transferred ? 177 - How much data was being transferred ?
178 - Was the network congested ? 178 - Was the network congested ?
179 - If there was a kernel panic, please run the output through ksymoops
180 before sending it to me, otherwise its _useless_.
181 - How can the problem be reproduced ? 179 - How can the problem be reproduced ?
182 - Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of 180 - Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of
183 tcpdump don't understand how to dump DECnet properly, so including 181 tcpdump don't understand how to dump DECnet properly, so including
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 66eaaab7773d..c563842ed805 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -1,6 +1,6 @@
1NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format 1NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format
2(from dmesg, etc). Ignore any references in this or other docs to "decoding 2(from dmesg, etc). Ignore any references in this or other docs to "decoding
3the Oops" or "running it through ksymoops". If you post an Oops fron 2.6 that 3the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that
4has been run through ksymoops, people will just tell you to repost it. 4has been run through ksymoops, people will just tell you to repost it.
5 5
6Quick Summary 6Quick Summary
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze
index 51f8d4379a94..4259dccc8287 100644
--- a/Documentation/video4linux/bttv/README.freeze
+++ b/Documentation/video4linux/bttv/README.freeze
@@ -27,9 +27,9 @@ information out of a register+stack dump printed by the kernel on
27protection faults (so-called "kernel oops"). 27protection faults (so-called "kernel oops").
28 28
29If you run into some kind of deadlock, you can try to dump a call trace 29If you run into some kind of deadlock, you can try to dump a call trace
30for each process using sysrq-t (see Documentation/sysrq.txt). ksymoops 30for each process using sysrq-t (see Documentation/sysrq.txt).
31will translate these dumps into kernel symbols too. This way it is 31This way it is possible to figure where *exactly* some process in "D"
32possible to figure where *exactly* some process in "D" state is stuck. 32state is stuck.
33 33
34I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid 34I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
35for some people. Thus probably a small buglet left somewhere in bttv 35for some people. Thus probably a small buglet left somewhere in bttv