On Fri, 2005-03-25 at 21:07 +0000, Russell King wrote: > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 07:38 +0000, Russell King wrote: > > > Users need to be re-educated _not_ to use ksymoops. > > > > How about changing the fscking docs to not tell users to use it? > > Would be useful. The "fscking" problem is that no one actually owns the > documents, so there's no central focus to keep them up to date. >
Are you serious? So Documentation/sound/alsa/* isn't maintained by the ALSA maintainers? Wow, this would explain why all Linux documentation is at least 2 years out of date. > Maybe we need a docfsck? 8) > > I certainly don't have authority to tell x86 people not to use ksymoops. > Therefore, I think my suggested change (which up until recently I thought > was an ARM only problem) should be done by someone else. > At least from my experience, ksymoops is useless on x86 for 2.6 kernels. Here is a patch to finally bring oops-tracing.txt into the 2.6 era. :-P Sugned-Off-By: Lee Revell <[EMAIL PROTECTED]> Lee --- Documentation/oops-tracing.txt~ 2005-03-17 20:34:06.000000000 -0500 +++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.000000000 -0500 @@ -1,23 +1,22 @@ +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 +has been run through ksymoops, people will just tell you to repost it. + Quick Summary ------------- -Install ksymoops from -ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops -Read the ksymoops man page. -ksymoops < the_oops.txt - -and send the output the maintainer of the kernel area that seems to be -involved with the problem, not to the ksymoops maintainer. Don't worry -too much about getting the wrong person. If you are unsure send it to -the person responsible for the code relevant to what you were doing. -If it occurs repeatably try and describe how to recreate it. Thats -worth even more than the oops +Find the Oops and send it to the maintainer of the kernel area that seems to be +involved with the problem. Don't worry too much about getting the wrong person. +If you are unsure send it to the person responsible for the code relevant to +what you were doing. If it occurs repeatably try and describe how to recreate +it. That's worth even more than the oops. If you are totally stumped as to whom to send the report, send it to [EMAIL PROTECTED] Thanks for your help in making Linux as stable as humanly possible. -Where is the_oops.txt? +Where is the Oops? ---------------------- Normally the Oops text is read from the kernel buffers by klogd and @@ -43,15 +42,14 @@ them yourself. Search kernel archives for kmsgdump, lkcd and oops+smram. -No matter how you capture the log output, feed the resulting file to -ksymoops along with /proc/ksyms and /proc/modules that applied at the -time of the crash. /var/log/ksymoops can be useful to capture the -latter, man ksymoops for details. - Full Information ---------------- +NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it +for historical reasons, and because some of the information in it still +applies. Especially, please ignore any references to ksymoops. + From: Linus Torvalds <[EMAIL PROTECTED]> How to track down an Oops.. [originally a mail to linux-kernel] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
