From: Jesper Juhl Update ksymoops related documentation to reflect current 2.6 reality. Signed-off-by: Jesper Juhl Signed-off-by: Andrew Morton --- 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(-) diff -puN Documentation/Changes~ksymoops-related-docs-update Documentation/Changes --- devel/Documentation/Changes~ksymoops-related-docs-update 2005-10-15 13:42:33.000000000 -0700 +++ devel-akpm/Documentation/Changes 2005-10-15 13:42:33.000000000 -0700 @@ -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 ----------------- diff -puN Documentation/filesystems/devfs/README~ksymoops-related-docs-update Documentation/filesystems/devfs/README --- devel/Documentation/filesystems/devfs/README~ksymoops-related-docs-update 2005-10-15 13:42:33.000000000 -0700 +++ devel-akpm/Documentation/filesystems/devfs/README 2005-10-15 13:42:33.000000000 -0700 @@ -1812,11 +1812,6 @@ it may overflow the messages buffer, but 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. diff -puN Documentation/networking/decnet.txt~ksymoops-related-docs-update Documentation/networking/decnet.txt --- devel/Documentation/networking/decnet.txt~ksymoops-related-docs-update 2005-10-15 13:42:33.000000000 -0700 +++ devel-akpm/Documentation/networking/decnet.txt 2005-10-15 13:42:33.000000000 -0700 @@ -176,8 +176,6 @@ information (_most_ of which _is_ _essen - 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 diff -puN Documentation/oops-tracing.txt~ksymoops-related-docs-update Documentation/oops-tracing.txt --- devel/Documentation/oops-tracing.txt~ksymoops-related-docs-update 2005-10-15 13:42:33.000000000 -0700 +++ devel-akpm/Documentation/oops-tracing.txt 2005-10-15 13:42:33.000000000 -0700 @@ -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 diff -puN Documentation/video4linux/bttv/README.freeze~ksymoops-related-docs-update Documentation/video4linux/bttv/README.freeze --- devel/Documentation/video4linux/bttv/README.freeze~ksymoops-related-docs-update 2005-10-15 13:42:33.000000000 -0700 +++ devel-akpm/Documentation/video4linux/bttv/README.freeze 2005-10-15 13:42:33.000000000 -0700 @@ -27,9 +27,9 @@ information out of a register+stack dump 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 _