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: 51+ 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: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:33 ` 2.6.12-rc1-mm2 Laurent Riffard
2005-03-24 23:49 ` 2.6.12-rc1-mm2 Andrew Morton
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 1:00 ` 2.6.12-rc1-mm2 Patrick Mochel
2005-03-25 6:05 ` 2.6.12-rc1-mm2 Greg KH
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-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.