Bug#432271: ksymoops output from another Appletalk module oops
Here is output from a second incidence of this bug. This crash occurred
just this afternoon.
ksymoops 2.4.11 on i686 2.6.18-4-686. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.18-4-686/ (default)
-m /boot/System.map-2.6.18-4-686 (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.
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
1151MB HIGHMEM available.
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ehci_hcd 0000:00:1d.7: debug port 1
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfe6fe000, irq 217, MAC addr 00:04:23:B3:84:15
e1000: 0000:01:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:04:23:b3:84:14
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
EDAC MC: Ver: 2.0.1 May 9 2007
EDAC i82875p: i82875p init one
EDAC MC0: Giving out device to i82875p_edac i82875p: DEV 0000:00:00.0
SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
lo: Disabled Privacy Extensions
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
f8ab0c2b
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<f8ab0c2b>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286 (2.6.18-4-686 #1)
eax: 00000000 ebx: 0000001f ecx: 00000000 edx: 01cc3280
esi: 00000000 edi: f78b7600 ebp: f6f87f44 esp: f6f87d80
ds: 007b es: 007b ss: 0068
Stack: 0000000c f6f87f44 ffffffa6 f6f87f60 f6f87ec4 ce7d1d80 00000000 00000002
f7264228 f6f87ec4 f8aafd3b f6f87f44 f78b7600 00000000 f6f87f44 f694ab80
f6f87dec f6f87f44 f694ab80 f6f87df0 f6f87f44 f8aafa74 0000000b f8ab1560
Call Trace:
[<f8aafd3b>] atalk_recvmsg+0xca/0xdb [appletalk]
[<f8aafa74>] __lock_atalk_dgram_sendmsg+0x1d/0x2b [appletalk]
[<c021fed7>] sock_sendmsg+0xce/0xe8
[<c012d92d>] autoremove_wake_function+0x0/0x2d
[<c0125380>] lock_timer_base+0x15/0x2f
[<c010205b>] setup_sigcontext+0x107/0x18e
[<c0126258>] __dequeue_signal+0x151/0x15c
[<c0220434>] sys_sendto+0x116/0x140
[<c0102819>] do_notify_resume+0x4e4/0x5d7
[<c012fdd9>] hrtimer_cancel+0xa/0x14
[<c02217b5>] sys_socketcall+0xeb/0x181
[<c0102c11>] sysenter_past_esp+0x56/0x79
Code: 0f b7 40 0c 8d 5c 08 0c 8b 44 24 10 66 83 78 04 00 75 06 80 78 06 00 75 1c 8b 44 24 10 83 c0 04 e8 79 e6 ff ff 85 ff 89 44 24 18 <8b> 10 89 54 24 14 75 26 eb 42 c6 44 24 3e 00 0f b7 87 56 01 00
>>EIP; f8ab0c2b <pg0+38725c2b/3fc73400> <=====
>>edx; 01cc3280 <phys_startup_32+1bc3280/c0000000>
>>edi; f78b7600 <pg0+3752c600/3fc73400>
>>ebp; f6f87f44 <pg0+36bfcf44/3fc73400>
>>esp; f6f87d80 <pg0+36bfcd80/3fc73400>
Trace; f8aafd3b <pg0+38724d3b/3fc73400>
Trace; f8aafa74 <pg0+38724a74/3fc73400>
Trace; c021fed7 <sock_sendmsg+ce/e8>
Trace; c012d92d <autoremove_wake_function+0/2d>
Trace; c0125380 <lock_timer_base+15/2f>
Trace; c010205b <setup_sigcontext+107/18e>
Trace; c0126258 <__dequeue_signal+151/15c>
Trace; c0220434 <sys_sendto+116/140>
Trace; c0102819 <do_notify_resume+4e4/5d7>
Trace; c012fdd9 <hrtimer_cancel+a/14>
Trace; c02217b5 <sys_socketcall+eb/181>
Trace; c0102c11 <sysenter_past_esp+56/79>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; f8ab0c00 <pg0+38725c00/3fc73400>
00000000 <_EIP>:
Code; f8ab0c00 <pg0+38725c00/3fc73400>
0: 0f b7 40 0c movzwl 0xc(%eax),%eax
Code; f8ab0c04 <pg0+38725c04/3fc73400>
4: 8d 5c 08 0c lea 0xc(%eax,%ecx,1),%ebx
Code; f8ab0c08 <pg0+38725c08/3fc73400>
8: 8b 44 24 10 mov 0x10(%esp),%eax
Code; f8ab0c0c <pg0+38725c0c/3fc73400>
c: 66 83 78 04 00 cmpw $0x0,0x4(%eax)
Code; f8ab0c11 <pg0+38725c11/3fc73400>
11: 75 06 jne 19 <_EIP+0x19>
Code; f8ab0c13 <pg0+38725c13/3fc73400>
13: 80 78 06 00 cmpb $0x0,0x6(%eax)
Code; f8ab0c17 <pg0+38725c17/3fc73400>
17: 75 1c jne 35 <_EIP+0x35>
Code; f8ab0c19 <pg0+38725c19/3fc73400>
19: 8b 44 24 10 mov 0x10(%esp),%eax
Code; f8ab0c1d <pg0+38725c1d/3fc73400>
1d: 83 c0 04 add $0x4,%eax
Code; f8ab0c20 <pg0+38725c20/3fc73400>
20: e8 79 e6 ff ff call ffffe69e <_EIP+0xffffe69e>
Code; f8ab0c25 <pg0+38725c25/3fc73400>
25: 85 ff test %edi,%edi
Code; f8ab0c27 <pg0+38725c27/3fc73400>
27: 89 44 24 18 mov %eax,0x18(%esp)
This decode from eip onwards should be reliable
Code; f8ab0c2b <pg0+38725c2b/3fc73400>
00000000 <_EIP>:
Code; f8ab0c2b <pg0+38725c2b/3fc73400> <=====
0: 8b 10 mov (%eax),%edx <=====
Code; f8ab0c2d <pg0+38725c2d/3fc73400>
2: 89 54 24 14 mov %edx,0x14(%esp)
Code; f8ab0c31 <pg0+38725c31/3fc73400>
6: 75 26 jne 2e <_EIP+0x2e>
Code; f8ab0c33 <pg0+38725c33/3fc73400>
8: eb 42 jmp 4c <_EIP+0x4c>
Code; f8ab0c35 <pg0+38725c35/3fc73400>
a: c6 44 24 3e 00 movb $0x0,0x3e(%esp)
Code; f8ab0c3a <pg0+38725c3a/3fc73400>
f: 0f .byte 0xf
Code; f8ab0c3b <pg0+38725c3b/3fc73400>
10: b7 87 mov $0x87,%bh
Code; f8ab0c3d <pg0+38725c3d/3fc73400>
12: 56 push %esi
Code; f8ab0c3e <pg0+38725c3e/3fc73400>
13: 01 00 add %eax,(%eax)
EIP: [<f8ab0c2b>] atalk_sendmsg+0x128/0x4c7 [appletalk] SS:ESP 0068:f6f87d80
Warning (Oops_read): Code line not seen, dumping what data is available
>>EIP; f8ab0c2b <pg0+38725c2b/3fc73400> <=====
2 warnings and 1 error issued. Results may not be reliable.
--
William Aoki KD7YAF waoki@umnh.utah.edu 5-1924
Reply to: