From owner-freebsd-net Sun May 6 6:38:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 18FEC37B422 for ; Sun, 6 May 2001 06:38:06 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([64.228.153.241]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010506133805.CGXS25498.tomts13-srv.bellnexxia.net@xena.gsicomp.on.ca>; Sun, 6 May 2001 09:38:05 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f46DZTN33443; Sun, 6 May 2001 09:35:29 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002301c0d631$02440e50$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Brian Somers" Cc: , References: <200105061140.f46BeuB54870@hak.lan.Awfulhak.org> Subject: Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable. Date: Sun, 6 May 2001 09:32:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm not sure if it's just fxp0 -- a few weeks ago a few people reported this very same problem with PPPoE for cards other than fxp0. Adding an ifconfig_xxx="up" to /etc/rc.conf (as suggested by an article on daemonnews or freebsddiary) "fixed" the problems for the people that I heard about -- but you're right that it isn't the best solution. The problem is this: if a card is down, it's because a) it's never been configured or b) it was downed manually. In the former case, we want PPPoE to initialize and start using the card (since you'd never have to initialize the NIC being used for PPPoE.) However, in case b), the driver should just ignore the data. How can we differentiate between case a) and case b)? I could see some admins getting pretty peeved if they 'ifconfig down fxp0' and then a few seconds later, PPPoE brings the interface back up to send data. (Of course, it would be better to kill the PPPoE daemon first before doing that, but...) > PPPoE now brings the interface IFF_UP before using it, but this isn't > the right solution (someone could manually down it again). > > fxp should just drop data if it's not up. > > > I have a reproducible kernel panic in 4.3 stable caused (sort of) by > > netgraph, or maybe by fxp0 in conjunction with pppoe. It is caused by > > setting up and attempting to open a pppoe connection over an fxp > > interface, due to fxp_start being called before fxp device has been > > opened. (This only occurs if the fxp interface has not been configured > > in any way since since boot.) > > > > Maybe if ethernet if has not been opened, and is down, it should be brought up > > by opening it for pppoe similar to ifconfig bringing it up when an ip > > address is assigned ? > > > > Causing the fault is as simple as running user land ppp, configuring 'set line > > pppoe:fxp0' and then trying to open the link. > > > > Backtrace is as follows. > > #0 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 > > #1 0xc01e4de4 in ether_output_frame (ifp=0xc0cbea00, m=0xc09d3d00) at ../../net/if_ethersubr.c:399 > > #2 0xc01fac2c in ng_ether_rcv_lower (node=0xc0cd3100, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:629 > > #3 0xc01fab55 in ng_ether_rcvdata (hook=0xc0e0bf40, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:595 > > #4 0xc01f8401 in ng_send_data (hook=0xc0e0bfc0, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_base.c:1648 > > #5 0xc01fc6e9 in sendpacket (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:1451 > > #6 0xc01fb99e in pppoe_start (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:754 > > #7 0xc01fb824 in ng_pppoe_rcvmsg (node=0xc0da8ac0, msg=0xc0e0f800, retaddr=0xc0e0bf00 "[7]:", rptr=0xc643fe28) > > at ../../netgraph/ng_pppoe.c:660 > > #8 0xc01f7925 in ng_send_msg (here=0xc0d607c0, msg=0xc0e0f800, address=0xc0cd4650 ".:tun0", rptr=0xc643fe28) > > at ../../netgraph/ng_base.c:1180 > > #9 0xc01fc954 in ngc_send (so=0xc5d5dc00, flags=0, m=0xc09e1f00, addr=0xc0cd4620, control=0x0, p=0xc5f44700) > > at ../../netgraph/ng_socket.c:242 > > #10 0xc01bffcb in sosend (so=0xc5d5dc00, addr=0xc0cd4620, uio=0xc643fed0, top=0xc09e1f00, control=0x0, flags=0, p=0xc5f44700) > > at ../../kern/uipc_socket.c:611 > > #11 0xc01c377f in sendit (p=0xc5f44700, s=2, mp=0xc643ff10, flags=0) at ../../kern/uipc_syscalls.c:583 > > #12 0xc01c3882 in sendto (p=0xc5f44700, uap=0xc643ff80) at ../../kern/uipc_syscalls.c:636 > > #13 0xc03340ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077941491, tf_esi = -1077941498, tf_ebp = -1077940984, > > tf_isp = -968622124, tf_ebx = 672834760, tf_edx = -1077941500, tf_ecx = -1077941500, tf_eax = 133, tf_trapno = 7, tf_err = 2, > > tf_eip = 673075808, tf_cs = 31, tf_eflags = 518, tf_esp = -1077941588, tf_ss = 47}) at ../../i386/i386/trap.c:1150 > > > > Program received signal SIGSEGV, Segmentation fault. > > 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 > > 1083 txp = sc->cbl_last->next; > > > > (kgdb) print sc > > $1 = (struct fxp_softc *) 0xc0cbea00 > > (kgdb) print sc->cbl_last > > $2 = (struct fxp_cb_tx *) 0x0 > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message