From: Walt H <waltabbyh@comcast.net>
To: akpm@osdl.org
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.0-test6-mm4
Date: Sun, 05 Oct 2003 14:56:44 -0700 [thread overview]
Message-ID: <3F80939C.1020802@comcast.net> (raw)
In-Reply-To: <3F80717E.6060300@comcast.net>
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
Walt H wrote:
> Reverting RD0-initrd-B6.patch allows initrd to
> work again, and my machine to boot.
However, I get an oops after kernel init and while running the init
scripts.
[-- Attachment #2: decodedoops.txt --]
[-- Type: text/plain, Size: 3978 bytes --]
ksymoops 2.4.9 on i686 2.6.0-test6-mm1. Options used
-v /usr/src/linux-2.6.0-test6-mm4/vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.6.0-test6-mm4/ (specified)
-m /boot/System.map-2.6.0-test6-mm4 (specified)
No modules in ksyms, skipping objects
Unable to handle kernel NULL pointer dereference at virtual address 00000034
c01a36d4
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01a36d4>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010212
eax: 00000000 ebx: 00000000 ecx: 00007dec edx: 00000001
esi: 0000000a edi: f75c46a0 ebp: f7fa2a80 esp: f6cb3e40
ds: 007b es: 007b ss: 0068
Stack: f75c46a0 c03221c0 f6b9fc50 c0305643 c01a11c4 f6ba1240 f6b9fc50 0000000d
c030563f f75c46a0 ffffffea fffffff4 f6ba213c f6ba20d0 f6ba1240 c01792ef
f6ba20d0 f6ba1240 c0322160 00000000 f6cb3f70 f767f500 00000000 f6ba1300
Call Trace:
[<c01a11c4>] proc_pident_lookup+0x104/0x260
[<c01792ef>] real_lookup+0xcf/0x100
[<c0183592>] dput+0x22/0x2d0
[<c0179c58>] link_path_walk+0x668/0x9f0
[<c014ce7d>] buffered_rmqueue+0xed/0x1d0
[<c012bb4c>] do_exit+0x39c/0x4c0
[<c019fde4>] proc_info_read+0x74/0x160
[<c0168ea8>] filp_open+0x68/0x70
[<c0169ede>] vfs_read+0xbe/0x130
[<c016a1b2>] sys_read+0x42/0x70
[<c02cc36e>] sysenter_past_esp+0x43/0x65
Code: f3 01 c0 29 c2 be 0a 00 00 00 89 c8 f7 f6 89 da 89 94 24 b4 00 00 00 89 84 24 b0 00 00 00 8b 87 ac 05 00 00 8b 94 24 c0 00 00 00 <8b> 58 34 8b 70 2c 8b 47 40 89 84 24 ac 00 00 00 8b 87 64 01 00
>>EIP; c01a36d4 <proc_pid_stat+2c4/5a0> <=====
>>edi; f75c46a0 <_end+3718bbb0/3fbc4510>
>>ebp; f7fa2a80 <_end+37b69f90/3fbc4510>
>>esp; f6cb3e40 <_end+3687b350/3fbc4510>
Trace; c01a11c4 <proc_pident_lookup+104/260>
Trace; c01792ef <real_lookup+cf/100>
Trace; c0183592 <dput+22/2d0>
Trace; c0179c58 <link_path_walk+668/9f0>
Trace; c014ce7d <buffered_rmqueue+ed/1d0>
Trace; c012bb4c <do_exit+39c/4c0>
Trace; c019fde4 <proc_info_read+74/160>
Trace; c0168ea8 <filp_open+68/70>
Trace; c0169ede <vfs_read+be/130>
Trace; c016a1b2 <sys_read+42/70>
Trace; c02cc36e <sysenter_past_esp+43/65>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c01a36a9 <proc_pid_stat+299/5a0>
00000000 <_EIP>:
Code; c01a36a9 <proc_pid_stat+299/5a0>
0: f3 01 c0 repz add %eax,%eax
Code; c01a36ac <proc_pid_stat+29c/5a0>
3: 29 c2 sub %eax,%edx
Code; c01a36ae <proc_pid_stat+29e/5a0>
5: be 0a 00 00 00 mov $0xa,%esi
Code; c01a36b3 <proc_pid_stat+2a3/5a0>
a: 89 c8 mov %ecx,%eax
Code; c01a36b5 <proc_pid_stat+2a5/5a0>
c: f7 f6 div %esi
Code; c01a36b7 <proc_pid_stat+2a7/5a0>
e: 89 da mov %ebx,%edx
Code; c01a36b9 <proc_pid_stat+2a9/5a0>
10: 89 94 24 b4 00 00 00 mov %edx,0xb4(%esp,1)
Code; c01a36c0 <proc_pid_stat+2b0/5a0>
17: 89 84 24 b0 00 00 00 mov %eax,0xb0(%esp,1)
Code; c01a36c7 <proc_pid_stat+2b7/5a0>
1e: 8b 87 ac 05 00 00 mov 0x5ac(%edi),%eax
Code; c01a36cd <proc_pid_stat+2bd/5a0>
24: 8b 94 24 c0 00 00 00 mov 0xc0(%esp,1),%edx
This decode from eip onwards should be reliable
Code; c01a36d4 <proc_pid_stat+2c4/5a0>
00000000 <_EIP>:
Code; c01a36d4 <proc_pid_stat+2c4/5a0> <=====
0: 8b 58 34 mov 0x34(%eax),%ebx <=====
Code; c01a36d7 <proc_pid_stat+2c7/5a0>
3: 8b 70 2c mov 0x2c(%eax),%esi
Code; c01a36da <proc_pid_stat+2ca/5a0>
6: 8b 47 40 mov 0x40(%edi),%eax
Code; c01a36dd <proc_pid_stat+2cd/5a0>
9: 89 84 24 ac 00 00 00 mov %eax,0xac(%esp,1)
Code; c01a36e4 <proc_pid_stat+2d4/5a0>
10: 8b .byte 0x8b
Code; c01a36e5 <proc_pid_stat+2d5/5a0>
11: 87 64 01 00 xchg %esp,0x0(%ecx,%eax,1)
next prev parent reply other threads:[~2003-10-05 21:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-05 19:31 2.6.0-test6-mm4 Walt H
2003-10-05 21:56 ` Walt H [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-10-05 8:33 2.6.0-test6-mm4 Andrew Morton
2003-10-05 8:33 ` 2.6.0-test6-mm4 Andrew Morton
2003-10-05 9:26 ` 2.6.0-test6-mm4 Daniele Bellucci
2003-10-05 9:26 ` 2.6.0-test6-mm4 Daniele Bellucci
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=3F80939C.1020802@comcast.net \
--to=waltabbyh@comcast.net \
--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.