>
> That trace was against a slightly different System.map, which was correct
> enough for me not to notice. The real one is only slightly different...
>
Hi David,
Is this with the i4l cvs tree? Here, I can prevent the oopsen by adding
noccp to ipppd options. I've also had this _exact_ oops except mine didn't
get any farther than ip_local_deliver().
Anyway, just in case it's not entirely a cvs isdn issue, I'm including
my last couple of isdn oops variants. The second oops only happened once..
usually either the deadly oops you posted or the one below killed me.
-Mike
ippp: no decompressor defined!
Warning: kfree_skb passed an skb still on a list (from c01751c3)
[net/ipv4/ip_input.c:378]
Unable to handle NULL pointer dereference at virtual address 00000004
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c016ab54>]
EFLAGS: 00010046
eax: 00000000 ebx: 00000000 ecx: c444c51c edx: 00000297
esi: c444c480 edi: c02683e8 ebp: c444c480 esp: c0287f40
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c0287000)
Stack: c0286000 c0287f90 0000831c 00085f39 c0115f39 00000000 c0286000 c010ed9e
00000000 00000000 c0286000 c025e3e0 00008314 c0286000 c03c13b0 00000008
00000018 00000018 ffffff0f c010629b c03c13b0 c01062cf c0286000 c0287fe4
Call Trace: [<c0115f39>] [<c010ed9e>] [<c010629b>] [<c01062cf>]
[<c0107984>] [<c0106098>] [<c0106087>] [<c0106000>]
[<c0100176>]
Code: c7 40 04 04 7c 2b c0 a3 04 7c 2b c0 c7 06 00 00 00 00 c7 46
Using `/boot/2.1.125/System.map' to map addresses to symbols.
>>EIP: c016ab54 <net_bh+58/1d0>
Trace: c0115f39 <do_bottom_half+49/70>
Trace: c010ed9e <schedule+3e/270>
Trace: c010629b <sys_idle+63/a4>
Trace: c01062cf <sys_idle+97/a4>
Trace: c0107984 <system_call+34/40>
Trace: c0106098 <init>
Trace: c0106087 <cpu_idle+7/18>
Trace: c0106000 <get_options>
Trace: c0100176 <L6>
Code: c016ab54 <net_bh+58/1d0>
Code: c016ab54 <net_bh+58/1d0> c7 40 04 04 7c movl $0xc02b7c04,0x4(%eax)
Code: c016ab5b <net_bh+5f/1d0> a3 04 7c 2b c0 movl %eax,0xc02b7c04
Code: c016ab66 <net_bh+6a/1d0> c7 06 00 00 00 movl $0x0,(%esi)
This one wasn't deadly, but killed named and then klogd and syslogd in
immediate succession with identical oopsen.
ippp: no decompressor defined!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 00fcf000, %cr3 = 00fcf000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c01840f8>]
EFLAGS: 00010282
eax: 00000000 ebx: c0093504 ecx: c1018040 edx: c0093514
esi: c0fd1eec edi: c0093554 ebp: 00000200 esp: c0fd1e38
ds: 0018 es: 0018 ss: 0018
Process named (pid: 119, process nr: 15, stackpage=c0fd1000)
Stack: c0fd1f6c c0fd1f6c 00000000 c01885f7 c1018040 c0fd1f6c 00000200 00000040
00000000 c0fd1e6c c12b9098 00000200 00000040 00000010 c016661a c12b9098
c0fd1f6c 00000200 00000040 c0fd1ea0 00000040 c12b9098 c0fd1eec 00000200
Call Trace: [<c01885f7>] [<c016661a>] [<c0188584>] [<c0167448>] [<c01919ec>] [<c01665b4>] [<c01919ec>]
[<c0167225>] [<c0167cdb>] [<c0107984>]
Code: 66 8b 00 66 89 46 02 8b 43 20 8b 40 0c 89 46 04 8b 4c 24 28
Using `/boot/2.1.125/System.map' to map addresses to symbols.
>>EIP: c01840f8 <udp_recvmsg+bc/12c>
Trace: c01885f7 <inet_recvmsg+73/8c>
Trace: c016661a <sock_recvmsg+42/b4>
Trace: c01885f7 <inet_recvmsg+73/8c>
Trace: c0167448 <sys_recvfrom+a4/134>
Trace: c01919ec <unix_stream_sendmsg>
Trace: c01665b4 <sock_sendmsg+8c/b0>
Trace: c01919ec <unix_stream_sendmsg>
Trace: c0167225 <sys_send+81/dc>
Trace: c0167cdb <sys_socketcall+163/1dc>
Trace: c0107984 <system_call+34/40>
Code: c01840f8 <udp_recvmsg+bc/12c>
Code: c01840f8 <udp_recvmsg+bc/12c> 66 8b 00 movw (%eax),%ax
Code: c01840fb <udp_recvmsg+bf/12c> 66 89 46 02 movw %ax,0x2(%esi)
Code: c01840ff <udp_recvmsg+c3/12c> 8b 43 20 movl 0x20(%ebx),%eax
Code: c0184108 <udp_recvmsg+cc/12c> 8b 40 0c movl 0xc(%eax),%eax
Code: c018410b <udp_recvmsg+cf/12c> 89 46 04 movl %eax,0x4(%esi)
Code: c018410e <udp_recvmsg+d2/12c> 8b 4c 24 28 movl 0x28(%esp,1),%ecx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/