From: Miles Lane <miles.lane@gmail.com>
To: Andrew Morton <akpm@osdl.org>,
miles.lane@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Date: Fri, 25 Mar 2005 07:52:18 -0500 [thread overview]
Message-ID: <a44ae5cd05032504521e0db1d4@mail.gmail.com> (raw)
In-Reply-To: <20050325081359.C18596@flint.arm.linux.org.uk>
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:
root@Monkey100:/sys/class/i2c-adapter/i2c-1# ls
./ ../ device@
root@Monkey100:/sys/class/i2c-adapter/i2c-1# ls -l
Segmentation fault
root@Monkey100:/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
[<c010414e>] dump_stack+0x1e/0x20
[<c01f0b12>] kref_get+0x42/0x50
[<c01f005b>] kobject_get+0x1b/0x30
[<c01986f1>] sysfs_getlink+0x41/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
[<c010414e>] dump_stack+0x1e/0x20
[<c01f0b12>] kref_get+0x42/0x50
[<c01f005b>] kobject_get+0x1b/0x30
[<c019874d>] sysfs_getlink+0x9d/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
Unable to handle kernel paging request at virtual address 00001000
c0198479
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198479>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246 (2.6.12-rc1-mm2)
eax: 00000000 ebx: 00000000 ecx: ffffffff edx: f7c0181c
esi: 00000001 edi: 00001000 ebp: e7519e94 esp: e7519e88
ds: 007b es: 007b ss: 0068
Stack: 00000002 e4fdea1c f7c0181c e7519eb8 c0198651 f7c0181c 00000020 f7c0181c
e7519eb8 c039f820 e4fdea1c f7c0181c e7519edc c0198790 f7c018cc f7c0181c
e46a3000 f7c018cc e46a3000 fffffff4 e7519f10 e7519ef8 c019884f e4fdea1c
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
[<c0198651>] sysfs_get_target_path+0x21/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: 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<f2>
ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 e7 5b 89 f0 5e 5f
>>EIP; c0198479 <object_path_length+19/30> <=====
>>ecx; ffffffff <__kernel_rt_sigreturn+1bbf/????>
>>edx; f7c0181c <pg0+3773581c/3fb32400>
>>ebp; e7519e94 <pg0+2704de94/3fb32400>
>>esp; e7519e88 <pg0+2704de88/3fb32400>
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; c0198651 <sysfs_get_target_path+21/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; c019844e <object_depth+e/20>
00000000 <_EIP>:
Code; c019844e <object_depth+e/20>
0: 75 f8 jne fffffffa <_EIP+0xfffffffa>
Code; c0198450 <object_depth+10/20>
2: c9 leave
Code; c0198451 <object_depth+11/20>
3: c3 ret
Code; c0198452 <object_depth+12/20>
4: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi
Code; c0198459 <object_depth+19/20>
b: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi
Code; c0198460 <object_path_length+0/30>
12: 55 push %ebp
Code; c0198461 <object_path_length+1/30>
13: 89 e5 mov %esp,%ebp
Code; c0198463 <object_path_length+3/30>
15: 57 push %edi
Code; c0198464 <object_path_length+4/30>
16: 56 push %esi
Code; c0198465 <object_path_length+5/30>
17: 8b 55 08 mov 0x8(%ebp),%edx
Code; c0198468 <object_path_length+8/30>
1a: be 01 00 00 00 mov $0x1,%esi
Code; c019846d <object_path_length+d/30>
1f: 53 push %ebx
Code; c019846e <object_path_length+e/30>
20: 31 db xor %ebx,%ebx
Code; c0198470 <object_path_length+10/30>
22: 8b 3a mov (%edx),%edi
Code; c0198472 <object_path_length+12/30>
24: b9 ff ff ff ff mov $0xffffffff,%ecx
Code; c0198477 <object_path_length+17/30>
29: 89 d8 mov %ebx,%eax
This decode from eip onwards should be reliable
Code; c0198479 <object_path_length+19/30>
00000000 <_EIP>:
Code; c0198479 <object_path_length+19/30> <=====
0: f2 ae repnz scas %es:(%edi),%al <=====
Code; c019847b <object_path_length+1b/30>
2: f7 d1 not %ecx
Code; c019847d <object_path_length+1d/30>
4: 49 dec %ecx
Code; c019847e <object_path_length+1e/30>
5: 8b 52 24 mov 0x24(%edx),%edx
Code; c0198481 <object_path_length+21/30>
8: 8d 74 31 01 lea 0x1(%ecx,%esi,1),%esi
Code; c0198485 <object_path_length+25/30>
c: 85 d2 test %edx,%edx
Code; c0198487 <object_path_length+27/30>
e: 75 e7 jne fffffff7 <_EIP+0xfffffff7>
Code; c0198489 <object_path_length+29/30>
10: 5b pop %ebx
Code; c019848a <object_path_length+2a/30>
11: 89 f0 mov %esi,%eax
Code; c019848c <object_path_length+2c/30>
13: 5e pop %esi
Code; c019848d <object_path_length+2d/30>
14: 5f pop %edi
next prev parent reply other threads:[~2005-03-25 12:52 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-24 12:41 2.6.12-rc1-mm2 Andrew Morton
2005-03-24 14:40 ` 2.6.12-rc1-mm2 Stefano Rivoir
2005-03-24 15:13 ` 2.6.12-rc1-mm2 Manuel Lauss
2005-03-24 15:18 ` 2.6.12-rc1-mm2 Brice Goglin
2005-03-24 15:31 ` 2.6.12-rc1-mm2 Stefano Rivoir
2005-03-24 20:05 ` 2.6.12-rc1-mm2 Andrew Morton
2005-03-24 20:21 ` 2.6.12-rc1-mm2 Brice Goglin
2005-03-25 1:19 ` 2.6.12-rc1-mm2 Alexey Dobriyan
2005-03-24 15:09 ` 2.6.12-rc1-mm2 (build error In function `zft_init') Steven Cole
2005-03-24 15:55 ` 2.6.12-rc1-mm2 (patch to fix build " Steven Cole
2005-03-24 21:49 ` Greg KH
2005-03-24 21:53 ` Andrew Morton
2005-03-24 16:46 ` 2.6.12-rc1-mm2 Lee Revell
2005-03-24 20:17 ` 2.6.12-rc1-mm2 Andrew Morton
2005-03-24 22:31 ` 2.6.12-rc1-mm2 Rafael J. Wysocki
2005-03-24 22:37 ` 2.6.12-rc1-mm2 Rafael J. Wysocki
2005-03-24 23:33 ` 2.6.12-rc1-mm2 Laurent Riffard
2005-03-24 23:49 ` 2.6.12-rc1-mm2 Andrew Morton
2005-03-25 1:00 ` 2.6.12-rc1-mm2 Patrick Mochel
2005-03-25 6:05 ` 2.6.12-rc1-mm2 Greg KH
2005-03-25 18:01 ` 2.6.12-rc1-mm2 Laurent Riffard
2005-05-26 0:29 ` 2.6.12-rc1-mm2 Andrew Morton
2005-05-26 13:58 ` 2.6.12-rc1-mm2 Rafael J. Wysocki
2005-03-25 0:38 ` [2.6 patch] remove exports for oem modules Adrian Bunk
2005-03-25 4:12 ` OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2 Miles Lane
2005-03-25 4:22 ` Andrew Morton
2005-03-25 7:38 ` Russell King
2005-03-25 7:45 ` Andrew Morton
2005-03-25 7:50 ` Russell King
2005-03-25 8:13 ` Russell King
2005-03-25 12:52 ` Miles Lane [this message]
2005-03-25 18:40 ` Andrew Morton
2005-03-25 19:50 ` Jean Delvare
2005-03-26 4:44 ` Miles Lane
2005-03-25 20:53 ` Lee Revell
2005-03-25 21:07 ` Russell King
2005-03-25 21:45 ` [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] Lee Revell
2005-03-25 21:52 ` Russell King
2005-03-25 21:54 ` Lee Revell
2005-03-25 19:26 ` x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2 Christophe Saout
2005-03-27 0:19 ` [PATCH] Fix preemption off of irq context on x86-64 with PREEMPT_BKL Christophe Saout
2005-03-27 17:28 ` Andi Kleen
2005-03-27 17:26 ` x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2 Andi Kleen
2005-03-27 18:05 ` Christophe Saout
2005-03-28 15:26 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a44ae5cd05032504521e0db1d4@mail.gmail.com \
--to=miles.lane@gmail.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox