Messages in this thread | | | Date | Tue, 4 Jul 2000 16:34:03 -0700 (PDT) | Subject | ppp(d) oops, very reproduceable, even avoidable | From | "Brian J. Murrell" <> |
| |
[ 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/
| |