Re: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:52 +, Russell King wrote: > On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > > > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > > > On Fri, 2005-03-25 at 07:38 +, 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? > > Last I checked, Documentation/oops-tracking.txt wasn't under > Documentation/sound/alsa. It seems obvious to me, but maybe it isn't > obvious to others, as your message appears to suggest. > No, I just misread your message as "none of the docs are maintained" rather than "oops-tracking.txt is not maintained". > As far as the question of ALSA documentation being up to date, that's > one set of directories in the kernel tree I've _never_ looked at, so > can't comment. Sorry. > The ALSA docs are in fact up to date. Lee - 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/
Re: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: > On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > > On Fri, 2005-03-25 at 07:38 +, 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? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
[PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 07:38 +, 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.0 -0500 +++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.0 -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..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/
[PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:07 +, Russell King wrote: On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, 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.0 -0500 +++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.0 -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/
Re: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2]
On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 21:07 +, Russell King wrote: On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, 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? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
Re: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:52 +, Russell King wrote: On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 21:07 +, Russell King wrote: On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, 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? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. No, I just misread your message as none of the docs are maintained rather than oops-tracking.txt is not maintained. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. The ALSA docs are in fact up to date. Lee - 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/
