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: 4+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox