diff options
| -rw-r--r-- | Documentation/Changes | 11 | ||||
| -rw-r--r-- | Documentation/filesystems/devfs/README | 5 | ||||
| -rw-r--r-- | Documentation/networking/decnet.txt | 2 | ||||
| -rw-r--r-- | Documentation/oops-tracing.txt | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/bttv/README.freeze | 6 |
5 files changed, 12 insertions, 14 deletions
diff --git a/Documentation/Changes b/Documentation/Changes index 783ddc3..86b8639 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -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 --git a/Documentation/filesystems/devfs/README b/Documentation/filesystems/devfs/README index 54366ec..aabfba2 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 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 --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt index c6bd25f..e6c39c5 100644 --- a/Documentation/networking/decnet.txt +++ b/Documentation/networking/decnet.txt @@ -176,8 +176,6 @@ information (_most_ of which _is_ _essential_) includes: - 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 --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index 66eaaab..c563842 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -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 --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze index 51f8d43..4259dcc 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 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 |
