From: Jesper Juhl <jesper.juhl@gmail.com>
To: "linux-kernel" <linux-kernel@vger.kernel.org>
Cc: "Richard E. Gooch" <rgooch@atnf.csiro.au>,
Patrick Caulfield <patrick@tykepenguin.com>,
Mauro Carvalho Chehab <mchehab@brturbo.com.br>,
Andrew Morton <akpm@osdl.org>, Chris Ricker <kaboom@gatech.edu>
Subject: [PATCH] ksymoops related docs update
Date: Sat, 15 Oct 2005 20:40:59 +0200 [thread overview]
Message-ID: <200510152040.59350.jesper.juhl@gmail.com> (raw)
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
reply other threads:[~2005-10-15 18:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200510152040.59350.jesper.juhl@gmail.com \
--to=jesper.juhl@gmail.com \
--cc=akpm@osdl.org \
--cc=kaboom@gatech.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@brturbo.com.br \
--cc=patrick@tykepenguin.com \
--cc=rgooch@atnf.csiro.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome