does the attached oops makes sense or it is just messed up?
AFAICT the ksymoops is using right System.map, yet the stack
trace does not seem to follow logical order. it is from 2.4.6-pre1
for that matter is "defensive" programming the rule in kernel?
this ops could be avoided if the net/ipv4/ipmr.c:ipmr_new_tunel()
function was changed to check whether 'v' is null and if it is
true then just return.
I did not submit this patch though since I couldn't figure how
in the the first place code ended up there.
--
Adam
http://www.eax.com The Supreme Headquarters of the 32 bit registers
ksymoops 2.4.0 on i686 2.4.6-pre1-packet. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.6-pre1-packet/ (default)
-m /boot/System.map-2.4.6-pre1-packet (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not
found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol do_softirq_R__ver_do_softirq not found in
System.map. Ignoring ksyms_base entry
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01b4a50,
System.map says c0157cf0. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
tasklet_hi_schedule_R__ver_tasklet_hi_schedule not found in System.map. Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol tasklet_schedule_R__ver_tasklet_schedule not
found in System.map. Ignoring ksyms_base entry
cpu: 0, clocks: 1002388, slice: 334129
cpu: 1, clocks: 1002388, slice: 334129
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
c01fbd2d
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c01fbd2d>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000100
esi: 06c71bbf edi: c71bbe4c ebp: c71bbe18 esp: c71bbe18
ds: 0018 es: 0018 ss: 0018
Process gaim (pid: 19160, stackpage=c71bb000)
Stack: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 0000009e c5e8781e c6ed0540
00000000 c6a37140 00000010 cc874144 00000001 00000000 00000000 00000000
Call Trace: [<cc874144>] [<c01bb281>] [<c0130584>] [<c01d8ebe>] [<c01414d9>]
[<c01ba6af>] [<c014743d>]
[<c01bb2fd>] [<c01bb994>] [<c0106fff>] [<c010002b>]
Code: 8b 43 0c 89 44 24 30 8b 43 08 c6 44 24 20 45 c6 44 24 29 04
>>EIP; c01fbd2d <ipmr_new_tunnel+2d/f0> <=====
Trace; cc874144 <[tulip]tulip_interrupt+5d4/780>
Trace; c01bb281 <sys_recvfrom+a1/100>
Trace; c0130584 <__alloc_pages+74/270>
Trace; c01d8ebe <tcp_poll+2e/150>
Trace; c01414d9 <pipe_poll+29/70>
Trace; c01ba6af <sock_poll+1f/30>
Trace; c014743d <do_pollfd+1d/80>
Trace; c01bb2fd <sys_recv+1d/30>
Trace; c01bb994 <sys_socketcall+154/200>
Trace; c0106fff <system_call+37/3c>
Trace; c010002b <startup_32+2b/cb>
Code; c01fbd2d <ipmr_new_tunnel+2d/f0>
00000000 <_EIP>:
Code; c01fbd2d <ipmr_new_tunnel+2d/f0> <=====
0: 8b 43 0c mov 0xc(%ebx),%eax <=====
Code; c01fbd30 <ipmr_new_tunnel+30/f0>
3: 89 44 24 30 mov %eax,0x30(%esp,1)
Code; c01fbd34 <ipmr_new_tunnel+34/f0>
7: 8b 43 08 mov 0x8(%ebx),%eax
Code; c01fbd37 <ipmr_new_tunnel+37/f0>
a: c6 44 24 20 45 movb $0x45,0x20(%esp,1)
Code; c01fbd3c <ipmr_new_tunnel+3c/f0>
f: c6 44 24 29 04 movb $0x4,0x29(%esp,1)
6 warnings issued. Results may not be reliable.
