Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, 25 Mar 2005 20:50:35 +0100, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > > > ./ ../ device@ > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > > > Segmentation fault > > > > What device is that, and which driver is handling it? > > If I am allowed a wild guess here... Isn't by any chance i2c-1 one the > the 3 i2c adapters exported by the nvidiafb driver, which we know isn't > playing nicely with the i2c core? To me, it is simply a different > expression of the same bug Miles hit some days ago when loading the > i2c-dev or eeprom modules [1]. You are exactly right. The /sys issues had to do with i2c stuff associated the nvidiafb driver. Miles - 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/
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/
Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
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. 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. -- 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
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? Seems like lots of stuff in Documentation/ is stuck in 2.4 land. How about purging it? Incorrect docs are worse than nothing. 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Hi Andrew, Miles, > > Andrew, this command causes the Oops for me: > > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > > ./ ../ device@ > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > > Segmentation fault > > What device is that, and which driver is handling it? If I am allowed a wild guess here... Isn't by any chance i2c-1 one the the 3 i2c adapters exported by the nvidiafb driver, which we know isn't playing nicely with the i2c core? To me, it is simply a different expression of the same bug Miles hit some days ago when loading the i2c-dev or eeprom modules [1]. Miles, do you have the same problem with i2c-0 and i2c-2, or only i2c-1? Can you please confirm that with CONFIG_FB_NVIDIA_I2C unset, the oops vanishes? [1] http://archives.andrew.net.au/lm-sensors/msg29974.html Thanks, -- Jean Delvare - 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Miles Lane <[EMAIL PROTECTED]> wrote: > > Ahem. In this case, I think it was operator error. I reproduced the > problem and have included the entire output of ksymoops below. Please don't use ksymoops. 2.6 kernels decode oopses internally and ksymoops actually removes a little info. > Andrew, this command causes the Oops for me: > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > ./ ../ device@ > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > Segmentation fault What device is that, and which driver is handling it? - 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Ahem. In this case, I think it was operator error. I reproduced the problem and have included the entire output of ksymoops below. Andrew, this command causes the Oops for me: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# dmesg|ksymoops -o /lib/modules/2.6.12-rc1-mm2 -m /boot/System.map-2.6.12-rc1-mm2 ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod [] dump_stack+0x1e/0x20 [] kref_get+0x42/0x50 [] kobject_get+0x1b/0x30 [] sysfs_getlink+0x41/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb [] dump_stack+0x1e/0x20 [] kref_get+0x42/0x50 [] kobject_get+0x1b/0x30 [] sysfs_getlink+0x9d/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb Unable to handle kernel paging request at virtual address 1000 c0198479 *pde = Oops: [#1] CPU:0 EIP:0060:[]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210246 (2.6.12-rc1-mm2) eax: ebx: ecx: edx: f7c0181c esi: 0001 edi: 1000 ebp: e7519e94 esp: e7519e88 ds: 007b es: 007b ss: 0068 Stack: 0002 e4fdea1c f7c0181c e7519eb8 c0198651 f7c0181c 0020 f7c0181c e7519eb8 c039f820 e4fdea1c f7c0181c e7519edc c0198790 f7c018cc f7c0181c e46a3000 f7c018cc e46a3000 fff4 e7519f10 e7519ef8 c019884f e4fdea1c Call Trace: [] show_stack+0x7f/0xa0 [] show_registers+0x15a/0x1c0 [] die+0xfc/0x190 [] do_page_fault+0x31b/0x670 [] error_code+0x4f/0x54 [] sysfs_get_target_path+0x21/0x80 [] sysfs_getlink+0xe0/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb Code: 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 57 56 8b 55 08 be 01 00 00 00 53 31 db 8b 3a b9 ff ff ff ff 89 d8 ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 e7 5b 89 f0 5e 5f >>EIP; c0198479<= >>ecx; <__kernel_rt_sigreturn+1bbf/> >>edx; f7c0181c >>ebp; e7519e94 >>esp; e7519e88 Trace; c010410f Trace; c01042aa Trace; c01044ac Trace; c011450b Trace; c0103cf3 Trace; c0198651 Trace; c0198790 Trace; c019884f Trace; c016b46f Trace; c01635b6 Trace; c0103249 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019844e <_EIP>: Code; c019844e 0: 75 f8 jnefffa <_EIP+0xfffa> Code; c0198450 2: c9leave Code; c0198451 3: c3ret Code; c0198452 4: 8d b4 26 00 00 00 00 lea0x0(%esi),%esi Code; c0198459 b: 8d bc 27 00 00 00 00 lea0x0(%edi),%edi Code; c0198460 12: 55push %ebp Code; c0198461 13: 89 e5 mov%esp,%ebp Code; c0198463 15: 57push %edi Code; c0198464 16: 56push %esi Code; c0198465 17: 8b 55 08 mov0x8(%ebp),%edx Code; c0198468 1a: be 01 00 00 00mov$0x1,%esi Code; c019846d 1f: 53push %ebx Code; c019846e 20: 31 db xor%ebx,%ebx Code; c0198470 22: 8b 3a mov(%edx),%edi Code; c0198472 24: b9 ff ff ff ffmov$0x,%ecx Code; c0198477 29: 89 d8 mov%ebx,%eax This decode from eip onwards should be reliable Code; c0198479 <_EIP>: Code; c0198479<= 0: f2 ae repnz scas %es:(%edi),%al <= Code; c019847b 2: f7 d1 not%ecx Code; c019847d 4: 49dec%ecx Code; c019847e 5: 8b 52 24 mov0x24(%edx),%edx Code; c0198481 8: 8d 74 31 01 lea0x1(%ecx,%esi,1),%esi Code; c0198485 c: 85 d2 test %edx,%edx Code; c0198487 e: 75 e7 jnefff7 <_EIP+0xfff7> Code; c0198489 10: 5bpop%ebx Code; c019848a 11: 89 f0 mov%esi,%eax Code; c019848c 13: 5epop%esi Code; c019848d 14: 5fpop%edi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More
Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 07:50:32AM +, Russell King wrote:
> On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote:
> > Russell King <[EMAIL PROTECTED]> wrote:
> > > On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote:
> > > > Miles Lane <[EMAIL PROTECTED]> wrote:
> > > > > Unable to handle kernel paging request at virtual address 24fc1024
> > > > > c0198448
> > > > > *pde =
> > > > > Oops: [#1]
> > > > > CPU:0
> > > > > EIP:0060:[]Not tainted VLI
> > > >
> > > > I wonder why the EIP sometimes doesn't get decoded.
> > > >
> > > > > Using defaults from ksymoops -t elf32-i386 -a i386
> > > > > EFLAGS: 00210206 (2.6.12-rc1-mm2)
> > >
> > > ksymoops seems to remove lines from the kernel output that it doesn't
> > > like.
> >
> > but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
> > saying that ksymoops rubbed that out and stuck a hex number in there?
>
> The kernel's x86 format is:
>
> printk("EIP: %04x:[<%08lx>] CPU: %d\n",0x & regs->xcs,regs->eip,
> smp_processor_id());
> print_symbol("EIP is at %s\n", regs->eip);
Argh, wrong one, it's supposed to be:
print_modules();
printk("CPU:%d\nEIP:%04x:[<%08lx>]%s VLI\nEFLAGS: %08lx"
" (%s) \n",
smp_processor_id(), 0x & regs->xcs, regs->eip,
print_tainted(), regs->eflags, system_utsname.release);
print_symbol("EIP is at %s\n", regs->eip);
but the result is the same. Also note that the modules line is also
missing from the posted oops.
(Why does x86 duplicate the register dumping between process.c and
traps.c ?)
--
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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 07:50:32AM +, Russell King wrote: On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote: Russell King [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: Miles Lane [EMAIL PROTECTED] wrote: Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there? The kernel's x86 format is: printk(EIP: %04x:[%08lx] CPU: %d\n,0x regs-xcs,regs-eip, smp_processor_id()); print_symbol(EIP is at %s\n, regs-eip); Argh, wrong one, it's supposed to be: print_modules(); printk(CPU:%d\nEIP:%04x:[%08lx]%s VLI\nEFLAGS: %08lx (%s) \n, smp_processor_id(), 0x regs-xcs, regs-eip, print_tainted(), regs-eflags, system_utsname.release); print_symbol(EIP is at %s\n, regs-eip); but the result is the same. Also note that the modules line is also missing from the posted oops. (Why does x86 duplicate the register dumping between process.c and traps.c ?) -- 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Miles Lane [EMAIL PROTECTED] wrote: Ahem. In this case, I think it was operator error. I reproduced the problem and have included the entire output of ksymoops below. Please don't use ksymoops. 2.6 kernels decode oopses internally and ksymoops actually removes a little info. Andrew, this command causes the Oops for me: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault What device is that, and which driver is handling it? - 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Hi Andrew, Miles, Andrew, this command causes the Oops for me: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault What device is that, and which driver is handling it? If I am allowed a wild guess here... Isn't by any chance i2c-1 one the the 3 i2c adapters exported by the nvidiafb driver, which we know isn't playing nicely with the i2c core? To me, it is simply a different expression of the same bug Miles hit some days ago when loading the i2c-dev or eeprom modules [1]. Miles, do you have the same problem with i2c-0 and i2c-2, or only i2c-1? Can you please confirm that with CONFIG_FB_NVIDIA_I2C unset, the oops vanishes? [1] http://archives.andrew.net.au/lm-sensors/msg29974.html Thanks, -- Jean Delvare - 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
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? Seems like lots of stuff in Documentation/ is stuck in 2.4 land. How about purging it? Incorrect docs are worse than nothing. 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
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. 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. -- 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.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/
Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Fri, 25 Mar 2005 20:50:35 +0100, Jean Delvare [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault What device is that, and which driver is handling it? If I am allowed a wild guess here... Isn't by any chance i2c-1 one the the 3 i2c adapters exported by the nvidiafb driver, which we know isn't playing nicely with the i2c core? To me, it is simply a different expression of the same bug Miles hit some days ago when loading the i2c-dev or eeprom modules [1]. You are exactly right. The /sys issues had to do with i2c stuff associated the nvidiafb driver. Miles - 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote:
> > > Miles Lane <[EMAIL PROTECTED]> wrote:
> > > > Unable to handle kernel paging request at virtual address 24fc1024
> > > > c0198448
> > > > *pde =
> > > > Oops: [#1]
> > > > CPU:0
> > > > EIP:0060:[]Not tainted VLI
> > >
> > > I wonder why the EIP sometimes doesn't get decoded.
> > >
> > > > Using defaults from ksymoops -t elf32-i386 -a i386
> > > > EFLAGS: 00210206 (2.6.12-rc1-mm2)
> >
> > ksymoops seems to remove lines from the kernel output that it doesn't
> > like.
>
> but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
> saying that ksymoops rubbed that out and stuck a hex number in there?
The kernel's x86 format is:
printk("EIP: %04x:[<%08lx>] CPU: %d\n",0x & regs->xcs,regs->eip,
smp_processor_id());
print_symbol("EIP is at %s\n", regs->eip);
so what you have there is the first EIP: line. The "EIP is at
symbol+0xN/0xM" is produced by the print_symbol statement, which
ksymoops decided to omit from the output.
It can be clearly seen from the rest of the oops (the call trace)
that print_symbol definitely does produce output, so kallsyms hasn't
been disabled.
> I wonder if there's something clever we could do to the kallsymsised oops
> output so that ksymoops would simply cease to recognise it.
I have been wondering why we still mark the addresses with [< >]
even though we've decoded them ourselves. Maybe omitting these
would be sufficient in the kallsyms-decoded case?
--
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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Russell King <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: > > Miles Lane <[EMAIL PROTECTED]> wrote: > > > Unable to handle kernel paging request at virtual address 24fc1024 > > > c0198448 > > > *pde = > > > Oops: [#1] > > > CPU:0 > > > EIP:0060:[]Not tainted VLI > > > > I wonder why the EIP sometimes doesn't get decoded. > > > > > Using defaults from ksymoops -t elf32-i386 -a i386 > > > EFLAGS: 00210206 (2.6.12-rc1-mm2) > > ksymoops seems to remove lines from the kernel output that it doesn't > like. but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there? > I've seen this many times on ARM, and each time I see an oops > from a 2.6 kernel which has been ksymoopsed, I always ask the submitter > to send the original non-ksymoopsed version. > > Users need to be re-educated _not_ to use ksymoops. I wonder if there's something clever we could do to the kallsymsised oops output so that ksymoops would simply cease to recognise it. - 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: > Miles Lane <[EMAIL PROTECTED]> wrote: > > Unable to handle kernel paging request at virtual address 24fc1024 > > c0198448 > > *pde = > > Oops: [#1] > > CPU:0 > > EIP:0060:[]Not tainted VLI > > I wonder why the EIP sometimes doesn't get decoded. > > > Using defaults from ksymoops -t elf32-i386 -a i386 > > EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. I've seen this many times on ARM, and each time I see an oops from a 2.6 kernel which has been ksymoopsed, I always ask the submitter to send the original non-ksymoopsed version. Users need to be re-educated _not_ to use ksymoops. -- 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: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Miles Lane <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l > [EMAIL PROTECTED]:/sys# cat */*/*/* > > ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used > -o /lib/modules/2.6.12-rc1-mm2 (specified) > -m /boot/System.map-2.6.12-rc1-mm2 (specified) > > Unable to handle kernel paging request at virtual address 24fc1024 > c0198448 > *pde = > Oops: [#1] > CPU:0 > EIP:0060:[]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00210206 (2.6.12-rc1-mm2) > eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 > esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 > ds: 007b es: 007b ss: 0068 > Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 > e75b6cc4 > f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 > e712a000 > fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea > e75b6cc4 > Call Trace: > [] show_stack+0x7f/0xa0 > [] show_registers+0x15a/0x1c0 > [] die+0xfc/0x190 > [] do_page_fault+0x31b/0x670 > [] error_code+0x4f/0x54 > [] sysfs_get_target_path+0x14/0x80 > [] sysfs_getlink+0xe0/0x150 > [] sysfs_follow_link+0x4f/0x60 > [] generic_readlink+0x2f/0x90 > [] sys_readlink+0x86/0x90 > [] syscall_call+0x7/0xb > Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 > 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b> > 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 > > > >>EIP; c0198448<= I can't repeat it here. Are you able to narrow it down to a specific sysfs file? The .config might help. - 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/
OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
[EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l [EMAIL PROTECTED]:/sys# cat */*/*/* ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 ds: 007b es: 007b ss: 0068 Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 e75b6cc4 f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000 fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea e75b6cc4 Call Trace: [] show_stack+0x7f/0xa0 [] show_registers+0x15a/0x1c0 [] die+0xfc/0x190 [] do_page_fault+0x31b/0x670 [] error_code+0x4f/0x54 [] sysfs_get_target_path+0x14/0x80 [] sysfs_getlink+0xe0/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b> 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 >>EIP; c0198448<= >>ebx; c039f820 >>edx; 24fc1000 >>esi; e75b6cc4 >>edi; f7c015e4 >>ebp; e7b93e94 >>esp; e7b93e94 Trace; c010410f Trace; c01042aa Trace; c01044ac Trace; c011450b Trace; c0103cf3 Trace; c0198644 Trace; c0198790 Trace; c019884f Trace; c016b46f Trace; c01635b6 Trace; c0103249 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d <.text.lock.dir+d7/fa> <_EIP>: Code; c019841d <.text.lock.dir+d7/fa> 0: 42inc%edx Code; c019841e <.text.lock.dir+d8/fa> 1: 70 e8 jo ffeb <_EIP+0xffeb> Code; c0198420 <.text.lock.dir+da/fa> 3: a4movsb %ds:(%esi),%es:(%edi) Code; c0198421 <.text.lock.dir+db/fa> 4: fccld Code; c0198422 <.text.lock.dir+dc/fa> 5: 19 00 sbb%eax,(%eax) Code; c0198424 <.text.lock.dir+de/fa> 7: e9 f3 fe ff ffjmpfeff <_EIP+0xfeff> Code; c0198429 <.text.lock.dir+e3/fa> c: 90nop Code; c019842a <.text.lock.dir+e4/fa> d: 90nop Code; c019842b <.text.lock.dir+e5/fa> e: 90nop Code; c019842c <.text.lock.dir+e6/fa> f: 90nop Code; c019842d <.text.lock.dir+e7/fa> 10: 90nop Code; c019842e <.text.lock.dir+e8/fa> 11: 90nop Code; c019842f <.text.lock.dir+e9/fa> 12: 90nop Code; c0198430 <.text.lock.dir+ea/fa> 13: 90nop Code; c0198431 <.text.lock.dir+eb/fa> 14: 90nop Code; c0198432 <.text.lock.dir+ec/fa> 15: 90nop Code; c0198433 <.text.lock.dir+ed/fa> 16: 90nop Code; c0198434 <.text.lock.dir+ee/fa> 17: 90nop Code; c0198435 <.text.lock.dir+ef/fa> 18: 90nop Code; c0198436 <.text.lock.dir+f0/fa> 19: 90nop Code; c0198437 <.text.lock.dir+f1/fa> 1a: 90nop Code; c0198438 <.text.lock.dir+f2/fa> 1b: 90nop Code; c0198439 <.text.lock.dir+f3/fa> 1c: 90nop Code; c019843a <.text.lock.dir+f4/fa> 1d: 90nop Code; c019843b <.text.lock.dir+f5/fa> 1e: 90nop Code; c019843c <.text.lock.dir+f6/fa> 1f: 90nop Code; c019843d <.text.lock.dir+f7/fa> 20: 90nop Code; c019843e <.text.lock.dir+f/60> Trace; c01681de <__link_path_walk+8ce/ec0> Trace; c016885f Trace; c0168c45 Trace; c01693ef Trace; c015823c Trace; c01586e8 Trace; c0103249 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d <.text.lock.dir+d7/fa> <_EIP>: Code; c019841d <.text.lock.dir+d7/fa> 0: 42inc%edx Code; c019841e <.text.lock.dir+d8/fa> 1: 70 e8 jo ffeb <_EIP+0xffeb> Code; c0198420 <.text.lock.dir+da/fa> 3: a4movsb %ds:(%esi),%es:(% -- <1>Unable to handle kernel paging request at virtual address 36bc3024 c0198448 *pde = Oops: [#6] CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210206 (2.6.12-rc1-mm2)
OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
[EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l [EMAIL PROTECTED]:/sys# cat */*/*/* ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 ds: 007b es: 007b ss: 0068 Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 e75b6cc4 f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000 fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea e75b6cc4 Call Trace: [c010410f] show_stack+0x7f/0xa0 [c01042aa] show_registers+0x15a/0x1c0 [c01044ac] die+0xfc/0x190 [c011450b] do_page_fault+0x31b/0x670 [c0103cf3] error_code+0x4f/0x54 [c0198644] sysfs_get_target_path+0x14/0x80 [c0198790] sysfs_getlink+0xe0/0x150 [c019884f] sysfs_follow_link+0x4f/0x60 [c016b46f] generic_readlink+0x2f/0x90 [c01635b6] sys_readlink+0x86/0x90 [c0103249] syscall_call+0x7/0xb Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 088b 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 EIP; c0198448 object_depth+8/20 = ebx; c039f820 sysfs_rename_sem+0/c edx; 24fc1000 phys_startup_32+24ec1000/c000 esi; e75b6cc4 pg0+270ebcc4/3fb33400 edi; f7c015e4 pg0+377365e4/3fb33400 ebp; e7b93e94 pg0+276c8e94/3fb33400 esp; e7b93e94 pg0+276c8e94/3fb33400 Trace; c010410f show_stack+7f/a0 Trace; c01042aa show_registers+15a/1c0 Trace; c01044ac die+fc/190 Trace; c011450b do_page_fault+31b/670 Trace; c0103cf3 error_code+4f/54 Trace; c0198644 sysfs_get_target_path+14/80 Trace; c0198790 sysfs_getlink+e0/150 Trace; c019884f sysfs_follow_link+4f/60 Trace; c016b46f generic_readlink+2f/90 Trace; c01635b6 sys_readlink+86/90 Trace; c0103249 syscall_call+7/b This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d .text.lock.dir+d7/fa _EIP: Code; c019841d .text.lock.dir+d7/fa 0: 42inc%edx Code; c019841e .text.lock.dir+d8/fa 1: 70 e8 jo ffeb _EIP+0xffeb Code; c0198420 .text.lock.dir+da/fa 3: a4movsb %ds:(%esi),%es:(%edi) Code; c0198421 .text.lock.dir+db/fa 4: fccld Code; c0198422 .text.lock.dir+dc/fa 5: 19 00 sbb%eax,(%eax) Code; c0198424 .text.lock.dir+de/fa 7: e9 f3 fe ff ffjmpfeff _EIP+0xfeff Code; c0198429 .text.lock.dir+e3/fa c: 90nop Code; c019842a .text.lock.dir+e4/fa d: 90nop Code; c019842b .text.lock.dir+e5/fa e: 90nop Code; c019842c .text.lock.dir+e6/fa f: 90nop Code; c019842d .text.lock.dir+e7/fa 10: 90nop Code; c019842e .text.lock.dir+e8/fa 11: 90nop Code; c019842f .text.lock.dir+e9/fa 12: 90nop Code; c0198430 .text.lock.dir+ea/fa 13: 90nop Code; c0198431 .text.lock.dir+eb/fa 14: 90nop Code; c0198432 .text.lock.dir+ec/fa 15: 90nop Code; c0198433 .text.lock.dir+ed/fa 16: 90nop Code; c0198434 .text.lock.dir+ee/fa 17: 90nop Code; c0198435 .text.lock.dir+ef/fa 18: 90nop Code; c0198436 .text.lock.dir+f0/fa 19: 90nop Code; c0198437 .text.lock.dir+f1/fa 1a: 90nop Code; c0198438 .text.lock.dir+f2/fa 1b: 90nop Code; c0198439 .text.lock.dir+f3/fa 1c: 90nop Code; c019843a .text.lock.dir+f4/fa 1d: 90nop Code; c019843b .text.lock.dir+f5/fa 1e: 90nop Code; c019843c .text.lock.dir+f6/fa 1f: 90nop Code; c019843d .text.lock.dir+f7/fa 20: 90nop Code; c019843e .text.lock.dir+f/60 Trace; c01681de __link_path_walk+8ce/ec0 Trace; c016885f link_path_walk+8f/190 Trace; c0168c45 path_lookup+95/170 Trace; c01693ef open_namei+7f/650 Trace; c015823c filp_open+3c/60 Trace; c01586e8 sys_open+48/d0 Trace; c0103249 syscall_call+7/b This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d .text.lock.dir+d7/fa _EIP: Code; c019841d .text.lock.dir+d7/fa 0: 42
Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Miles Lane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l [EMAIL PROTECTED]:/sys# cat */*/*/* ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 ds: 007b es: 007b ss: 0068 Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 e75b6cc4 f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000 fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea e75b6cc4 Call Trace: [c010410f] show_stack+0x7f/0xa0 [c01042aa] show_registers+0x15a/0x1c0 [c01044ac] die+0xfc/0x190 [c011450b] do_page_fault+0x31b/0x670 [c0103cf3] error_code+0x4f/0x54 [c0198644] sysfs_get_target_path+0x14/0x80 [c0198790] sysfs_getlink+0xe0/0x150 [c019884f] sysfs_follow_link+0x4f/0x60 [c016b46f] generic_readlink+0x2f/0x90 [c01635b6] sys_readlink+0x86/0x90 [c0103249] syscall_call+0x7/0xb Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 088b 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 EIP; c0198448 object_depth+8/20 = I can't repeat it here. Are you able to narrow it down to a specific sysfs file? The .config might help. - 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: Miles Lane [EMAIL PROTECTED] wrote: Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. I've seen this many times on ARM, and each time I see an oops from a 2.6 kernel which has been ksymoopsed, I always ask the submitter to send the original non-ksymoopsed version. Users need to be re-educated _not_ to use ksymoops. -- 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Russell King [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: Miles Lane [EMAIL PROTECTED] wrote: Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there? I've seen this many times on ARM, and each time I see an oops from a 2.6 kernel which has been ksymoopsed, I always ask the submitter to send the original non-ksymoopsed version. Users need to be re-educated _not_ to use ksymoops. I wonder if there's something clever we could do to the kallsymsised oops output so that ksymoops would simply cease to recognise it. - 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: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote: Russell King [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: Miles Lane [EMAIL PROTECTED] wrote: Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there? The kernel's x86 format is: printk(EIP: %04x:[%08lx] CPU: %d\n,0x regs-xcs,regs-eip, smp_processor_id()); print_symbol(EIP is at %s\n, regs-eip); so what you have there is the first EIP: line. The EIP is at symbol+0xN/0xM is produced by the print_symbol statement, which ksymoops decided to omit from the output. It can be clearly seen from the rest of the oops (the call trace) that print_symbol definitely does produce output, so kallsyms hasn't been disabled. I wonder if there's something clever we could do to the kallsymsised oops output so that ksymoops would simply cease to recognise it. I have been wondering why we still mark the addresses with [ ] even though we've decoded them ourselves. Maybe omitting these would be sufficient in the kallsyms-decoded case? -- 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/
