lkml.org 
[lkml]   [2000]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
Subjectppp(d) oops, very reproduceable, even avoidable
From
[ If you would be so kind as to CC me on responses I would appreciate
it. Thanx. ]

I have a very reproducable kernel oops with PPP. I am running a 2.2.14
kernel but have tried 2.2.17pre9 and the same problem exhibits itself.
This kernel has the kernel-mode PPPoE driver (0.47 as found at
http://www.davin.ottawa.on.ca/pppoe/) patched in.

The situation that causes the oops to happen is this:

The machine is PPPoE connected to the Internet and everything is working
fine:

78 ? S 0:00 /usr/sbin/pppoed -I eth0 -R 999 -F /etc/ppp/pppoe-pppd_options
2081 ? S 0:00 \_ pppd /dev/pppox0 38400 file /etc/ppp/pppoe-pppd_options

If the connection goes down (i.e pulling the cable from the PPPoE modem),
pppd notices because it fails to get a response to it's LCP-ECHO requests
and exits. Normal so far. pppoed then continues to try to reach the
PPPoE server. Once it has gotten a link again, pppoed starts pppd up at
which point I get the oops(es) included below. As a work-around, I can
actually prevent the oops(es). To achieve this, I have to unload the
ppp_deflate, rmmod bsd_comp and ppp kernel modules before the link comes
back up and pppd restarts. So my guess is that there is an issue with
(I think) the ppp module being requested to load while it is still loaded.
Or perhaps one of the compression modules being loaded is the problem. In
any case, if all three of those modules are unloaded when pppd stops,
everything comes back up fine when the link is restored.

The oops(es). There are two. They always happen in rapid fire pairs like
this:

Unable to handle kernel paging request at virtual address 838d5fb0
current->tss.cr3 = 02eab000, %cr3 = 02eab000
*pde = 02ffa063
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[bsd_comp:__insmod_bsd_comp_S.data_L56+512628/14589312]
EFLAGS: 00010282
eax: 838d5fb0 ebx: 81a3f0f4 ecx: 00000000 edx: 81899500
esi: 8020c754 edi: 8189954c ebp: 8020c6e8 esp: 818f5ea8
ds: 0018 es: 0018 ss: 0018
Process pppd (pid: 2177, process nr: 39, stackpage=818f5000)
Stack: 81899500 818995b8 81a3f0f4 81a3f0f4 80faee60 81899500 80170ea1 81a3f0f4
8020c6e8 80faee60 818f5f3c 818f5f4c 80faee60 818995a0 801711cd 81a3f0f4
00000000 80171915 81a3f0f4 80faee60 00008916 00008916 7ffffa6c 80a0a020
Call Trace: [inetdev_init+125/248] [inet_set_ifa+25/84] [devinet_ioctl+1129/1516] [notify_parent+177/192] [inet_ioctl+871/1040] [sock_ioctl+33/40] [sys_ioctl+420/444]
[sock_ioctl+0/40] [tracesys+24/35]
Code: <1>Unable to handle kernel paging request at virtual address 838d5fb0
current->tss.cr3 = 02eab000, %cr3 = 02eab000
*pde = 02ffa063
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[show_registers+619/668]
EFLAGS: 00010092
eax: 838d5fb0 ebx: 00000000 ecx: 00000005 edx: 819f2000
esi: 0000002b edi: 818f6000 ebp: 83800000 esp: 818f5de8
ds: 0018 es: 0018 ss: 0018
Process pppd (pid: 2177, process nr: 39, stackpage=818f5000)
Stack: 818f5e6c 000d5000 80232f42 8020c754 8189954c 8020c6e8 838d5fb0 81a3f0f4
00000000 81899500 838d5fb0 00010282 83800000 84000000 8010a3a4 818f5e6c
801d6fec 801d8138 00000000 00000000 8010f526 801d8138 818f5e6c 00000000
Call Trace: [bsd_comp:__insmod_bsd_comp_S.data_L56+512628/14589312] [bsd_comp:__insmod_bsd_comp_S.data_L56+512628/14589312] [ppp_deflate:__insmod_ppp_deflate_O/lib/modules/2.2.14-5.5/net/ppp_defla+-421888/76] [bsd_comp:__insmod_bsd_comp_S.data_L56+8024772/7077168] [die+48/56] [error_table+1860/6460] [error_table+6288/6460]
[do_page_fault+742/952] [error_table+6288/6460] [error_code+45/52] [bsd_comp:__insmod_bsd_comp_S.data_L56+512628/14589312] [bsd_comp:__insmod_bsd_comp_S.data_L56+512628/14589312] [neigh_parms_alloc+94/144] [inetdev_init+125/248] [inet_set_ifa+25/84]
[devinet_ioctl+1129/1516] [notify_parent+177/192] [inet_ioctl+871/1040] [sock_ioctl+33/40] [sys_ioctl+420/444] [sock_ioctl+0/40] [tracesys+24/35]
Code: 0f b6 0c 03 89 4c 24 38 51 68 e4 6f 1d 80 e8 f6 9c 00 00 83

I hope all of the needed info is in there. If not please don't hesitate
to say and I will provide whatever else is needed.

Thanx,
b.


--
Brian J. Murrell InterLinx Support Services, Inc.
North Vancouver, B.C. 604 983 UNIX
Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:1.127 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site